4. AppleTalk im OSI-Schichtenmodell
4.1 Das OSI-Schichtenmodell im Überblick
Nur eine klare Spezifikation der Aufgaben von Moduln und deren Schnittstellen gewährleistet die Portierbarkeit von Kommunikationssoftware auf unterschiedliche Systeme und Übertragungsmedien[1]. Rechnerkommunikation unterliegt genauen und komplexen Regeln, die zur besseren Überschaubarkeit systematisiert und auf ein Modell reduziert werden müssen. So wurde von der „International Standards Organisation“ das ISO/OSI-Schichtenmodell entworfen, um eine universell anwendbare logische Struktur für die Kommunikation von Rechnern auf einem Wide Area Network zu spezifizieren. Es handelt sich dabei um ein einheitliches Baukastenprinzip, das dazu beitragen soll, die Software-Entwicklung für Kommunikationssysteme zu systematisieren und zu modularisieren, um ein Bezugsmodell für offenen Systeme und nicht um eine Implementierungsvorschrift. OSI (Open System Interconnection) bedeutet in diesem Zusammenhang die einfache Austauschbarkeit von Schichten und Moduln eines Kommunikationssystems und der freie Zugang, sowie die Nutzbarkeit von Diensten auf allen Ebenen. Die Entwicklung von Kommunikationsprotokollen orientiert sich an der logischen Struktur eines Schichtenmodells. Das Schichtenmodell erleichtert den Vergleich von Systemen. Existierende Protokolle lassen sich somit nach ihren Aufgaben in das Modell einordnen[2]. Das OSI-Schichtenmodell ist ein bewährtes Architekturmodell und liegt heutigen Systemen fast ausnahmslos zugrunde.
4.1.1 Funktionale Einteilung in Schichten
Die funktionale Aufteilung von Kommunikationssoftware in Schichten bewirkt eine Strukturierung komplexer Kommunikationssysteme, ähnlich der Strukturierung von Programmen durch die Aufteilung in Prozeduren und Funktionen. Dabei ist darauf zu achten, daß der Überblick nicht durch zu komplexe Strukturen verloren geht und Anweisungen nach ihren Funktionen zu Moduln zusammengefaßt werden. Diese Moduln sollten klar definierte Aufgaben und schmale Schnittstellen besitzen, so daß sie auch in verschiedenen Techniken implementiert werden können.
|
7 |
Anwendungsschicht (Application Layer) |
Konkretisierung der Netzwerkdienste in Form von verarbeitenden Applikationen |
|
6 |
Darstellungsschicht (Presentation Layer) |
Festlegung der Bedeutung ausgetauschter Daten (Syntax) Realisierung der benutzer- und geräteunabhängigen Kommunikation |
|
5 |
Kommunikationssteuerungsschicht (Session Layer) |
Spezifikationen für die logische Punk-zu-Punk-Verbindung zwischen zwei Kommunikationsteilnehmern und deren Steuerung |
|
4 |
Transportschicht (Transport Layer) |
Festlegung von Funktionen zum gesicherten Transport von Daten zwischen Sender und Empfänger |
|
3 |
Vermittlungsschicht (Network Layer) |
Festlegungen zum Aufbau des Übertragungsweges und zur Vermittlung von Daten zwischen logischen Adressen im Netzwerk |
|
2 |
Sicherungsschicht (Link Layer) |
Spezifikationen zur gesicherten Übertragung von Daten in Paketen zwischen physikalischen Adressen |
|
1 |
Bitübertragungsschicht (Physical Layer) |
Festlegung der physikalischen Übertragungsparameter und der Schnittstelleneigenschaften |
Abb. 4.1.1: Die Schichten des OSI-Modells und ihre Funktionen
Die funktionale Partitionierung der Datenübertragung führt zur Definition von sieben logischen Ebenen, die im OSI-Modell Schichten genannt werden (siehe Abb. 4.1.1). Jede dieser Schichten stellt einen anderen Abstraktionsgrad dar und besitzt eine wohldefinierte Funktionalität. Sie nutzt die Dienste der untergeordneten Schicht und stellt ihrerseits wieder der übergeordneten Schicht Dienste zur Verfügung. Die OSI-Schichten lassen sich unterteilen in datenverarbeitende, anwenderbezogene und datenübertragende, übertragungstypische Schichten[3]. Jede Schicht kommuniziert scheinbar mit ihrem Partner über virtuelle Verbindungen[4] auf derselben Ebene (Peer Protocols). Nur auf der untersten Ebene besteht eine physikalische Verbindung. Eine Kommunikation zwischen zwei Einheiten ist nur mit Hilfe der Dienste der untergeordneten Schichten möglich. Durch Abstraktion bleiben dem Klienten einer Schicht die Details der Übertragung verborgen.
Abb. 4.1.2: Datenfluß im OSI-Schichtenmodell
Zwischen den Schichten befinden sich jeweils Schnittstellen, die möglichst schmal sein sollten, um den Austausch einzelner Schichten und eine Portierung auf andere Systeme zu erleichtern. Die Schnittstelle einer Schicht wird durch die Funktionen und Prozeduren festgelegt, die sie dem darüberliegen Klienten zur Verfügung stellt. Eine Schnittstelle besteht jedoch nicht nur aus der formalen Spezifikation der Parameter, sondern auch aus den Eigenschaften, dem Verhalten und der Leistungscharakteristik der beteiligten Schichten[5]. Über eine Schnittstelle soll nach Möglichkeit wenig Steuerinformation fließen.
Eine Schicht kommuniziert jeweils nur mit der nächst höheren und niedrigeren Schicht. Die einzelnen Schichten kommunizieren über sog. Schichtenprotokolle. Dabei werden den Nutzdaten, bevor sie an die unteren Schichten weitergegeben werden, noch Kontrollinformationen beigefügt[6] (vgl. Abb. 4.1.2). Diese Kontrollinformation kann unter Umständen einen beträchtlichen Protokolloverhead verursachen.
4.1.2 Die Schichten des OSI-Modells
4.1.2.1 Die physikalische Schicht
Die unterste, physikalische Schicht umfaßt alle Einzelheiten, die sich aus der Übermittlung von Signalen unterschiedlichster Art zur Informationsübertragung ergeben:
v Spezifikation des physikalischen Übertragungsmediums und der Kanaleigenschaften
v mechanische Kenndaten
v elektrische Schnittstelleneigenschaften
v die funktionalen und prozeduralen Parameter zur Aktivierung, Aufrechterhaltung und Deaktivierung von physikalischen Punkt-zu-Punkt- oder Mehrpunkt-Verbindungen zwischen physisch existierenden Stationen.
v die Erkennung einer Kollision von Meldungen beim Zugriff auf das Medium (CD).
Die primäre Funktion ist die transparente Übertragung eines Voll- oder Halbduplex-Bitstromes über permanente oder auch dynamische Verbindungen. Dabei muß die Bitfolge einer Nachricht erhalten bleiben. Eine Übertragung kann über verschiedenste Topologien, Überragungsmedien und Zwischensysteme erfolgen. Die Gegenstelle bei der Übertragung muß für die Verbindungsschicht identifizierbar sein. Fehlerrate, Verfügbarkeit[7] und Signalverzögerung bestimmen die Qualität einer physikalischen Verbindung. Ein Beispiel für eine Norm im Bereich der physikalischen Schicht ist die V.24-Norm.
4.1.2.2 Die Sicherungsschicht
Die Hauptaufgabe dieser Schicht ist die Bereitstellung von Funktionen, die eine transparente Übertragung von Frames oder Characters zwischen Einrichtungen der Netzwerkschicht gewährleisten. Die Sicherungsschicht überbrückt die Limitationen, die in physikalischen Leitungen inhärent vorhanden sind[8]. Insbesondere werden dabei Übertragungsfehler in ankommenden Meldungen, die durch die physikalische Schicht entstanden sind, entdeckt und, wenn möglich, korrigiert.
Meldungen werden mit Sender- und Empfangsadresse, mit Sequenznummern sowie mit Redundanz zur Kontrolle der Datenintegrität versehen, so daß in dieser Schicht Mittel zur Fehlererkennung, zur Datenflußkontrolle und zur Wegfindung zwischen jeweils zwei Punken bereitgestellt werden. Dies umfaßt auch die Synchronisation der Kommunikationspartner und die Rahmensynchronisation in bitorientierten Protokollen.
Die Verbindungsschicht definiert unter Berücksichtigung der Eigenheiten der physikalischen Schicht Regeln, die beim Zugriff auf das Übertragungsmedium für das Senden und Empfangen von Meldungen beachtet werden müssen. In lokalen Netzen wird die Sicherungsschicht oft in weitere Subschichten unterteilt, die eine spezielle Funktion erfüllen. Einer solchen Unterschicht kann zum Beispiel die Zugriffskontrolle auf das Übertragungsmedium (MAC) übertragen werden.
4.1.2.3 Die Netzwerkschicht
Typisch für ein LAN sind nur die unteren drei Schichten. Die Schichten darüber können sowohl auf einem LAN als auch auf einem WAN vorgefunden werden. Bei WANs sind die unteren Schichten durch die X.25-Norm weitgehend standardisiert.
Aufgabe der Netzwerkschicht ist die Weglenkung von Paketen in einem Wide Area Network. Da in einem reinen LAN normalerweise keine Weglenkung erforderlich ist, kann die Netzwerkschicht entfallen. Werden jedoch mehrere LAN-Zonen über Brücken miteinander verbunden (Internet), so übernimmt diese Schicht die Funktion der Weglenkung von Paketen durch die Subnetze über mehrere Link-Strecken zum Zielnetzwerk. Transporteinheiten und Subnetze werden durch logische Adressen identifiziert.
Die Netzwerkschicht sorgt für den Aufbau, die Aufrechterhaltung und den Abbau von Verbindungen über Teilstreckennetze. Dabei bleiben die Teilstrecken, über die Datagramme übertragen werden, der Transportschicht verborgen. Kriterien für eine optimale Weglenkung (Routing) können die Kosten einer Übertragungsleitung, die Länge des Weges, sowie die Auslastung eines Netzes sein. Da in den Brücken zwischen den Subsystemen meist eine Zwischenspeicherung der Pakete erfolgt, ist eine einfache Flußkontrolle notwendig[9]. Unterstützt wird ein transparenter Datenaustausch, wobei ein Multiplexen und Demultiplexen von an- und abgehenden Paketen möglich ist.
4.1.2.4 Die Transportschicht
Die Transportschicht bietet einen zuverlässigen, vom Übertragungsverfahren unabhängigen Transportdienst an. Sie enthält Funktionen zum Auf- und Abbau, sowie zur Aufrechterhaltung von mehreren virtuellen End-To-End-Transportverbindungen. Nachrichten der Klienten werden hier paketisiert und über einen variablen Transport-Mechanismus verlustfrei übertragen. Dieser Mechanismus beinhaltet Flußkontrolle und Fehlererkennung. Zerstörte Datenpakete werden wiederholt, wobei stets die Folgerichtigkeit des Informationsflußes beibehalten werden muß. Eine Transportverbindung kann mehrere Sessions unterstützen. Umgekehrt kann eine Session durch mehrere Transportverbindungen unterhalten werden. Eine weitere wichtige Aufgabe dieser Schicht ist die Zuordnung von Gerätenamen zu physikalischen und logischen Adressen[10].
Da die Transportschicht alle Details der Kommunikation zur Sitzungsschicht abschirmt und die darüberliegenden Schichten sich nicht mehr mit den Einzelheiten der Kommunikation beschäftigen müssen, ist diese Schicht eigentlich der Abschluß der transportorientierten Kommunikationsschichten.
4.1.2.5 Die Sitzungsschicht
Diese Schicht dient dem Aufbau, der Verwaltung und dem Beenden von Sitzungen (Sessions) an einem abgesetzten System. In einer Eröffnungsphase werden Zugriffsberechtigung und Verfügbarkeit von Systemen geprüft. Über eine Session-Identifikation werden Daten einer Session zugeordnet. Bei Störungen sorgt ein Recovery-Mechanismus für Fehlerbehandlung und -behebung. Für die Übertragung von Daten werden verschiedene Delimiter zur Datengruppierung verwendet. Die Synchronisation sowie Datenfluß- und Dialogkontrolle einer Session werden durch den Austausch von Kontrollinformationen realisiert.
Abb. 4.1.3: Konsekutive und konkurrente Sitzungen.
Obwohl keine eindeutige Zuordung zwischen Session- und Transportverbindung möglich ist, wird jede Sitzung zu einem bestimmten Zeitpunkt nur von genau einer Transportverbindung unterstützt. Entweder wird eine Transportverbindung von mehreren konsekutiven Session-Verbindungen benützt, oder eine konkurrente Session-Verbindung verwendet mehrere konsekutive Transportverbindungen[11] (Abb. 4.1.3). Im allgemeinen findet dieses Protokoll Anwendung im Zusammenhang mit dem Zugriff auf Host-Betriebssysteme. Oft wird diese Schicht mit der Transportschicht in einem Protokoll zusammengefaßt.
4.1.2.6 Die Präsentationsschicht
Diese Schicht übernimmt die Konvertierung, Interpretation und einheitliche Darstellung der Übertragungsdaten für die Anwendungsschicht. Falls notwendig findet eine Umwandlung zwischen unterschiedlichen Codes und Datenformaten statt. Somit sorgt die Präsentationsschicht für eine syntaktische Kompatibilität zwischen den Anwendungsprogrammen. Dadurch wird die Kommunikation in offenen Systemen ermöglicht, ohne daß Kosten für Interfaces, Datenumwandlungen und Modifikationen anfallen. Die Auswahl des Darstellungsverfahrens wird durch die Definition des Darstellungsbildes (Presentation Image Definition) vollzogen. Diese liefert die Interpretationsvorschrift für die Beschreibung von Daten und deren Manipulation[12]. Es werden Funktionen zur Erstellung von Inhalt und Struktur von Images zur Verfügung gestellt. Eine Kodierung von Information wird in einem offenen System häufig zur Sicherung vor unberechtigtem Zugriff verwendet.
4.1.2.7 Die Applikationsschicht
Eine Applikation im Sinne des Schichtenmodells besteht aus kommunizierenden Prozessen. Zu dieser Schicht gehören alle Prozesse, die sich der Kommunikationsdienste der Schichten 1–6 bedienen. Hier geschieht die Verwaltung und Verarbeitung von Kommunikationsdaten durch Prozesse, die der Kommunikationsunterstützung für Anwendungsprogramme dienen. Prozesse lassen sich unterteilen in Benutzer-Anwendungsprozesse, Anwendungs- und System-Verwaltungsprozesse[13]. Eine wichtige Kategorie stellen die Verteilten Systeme dar, deren Prozesse über ein Netz kommunizieren.
Schmale Interfaces und eine klare Definition der Schnittstellen sind für die Austauschbarkeit von Schichten in einem offenen System unabdingbar.
4.2 Der AppleTalk Protocol Stack
AppleTalk ist seit 1983 das Standard-Netzwerk für Macintosh-Rechner, von dem bisher bereits 52 Versionen freigegeben wurden. Es dient der seriellen Anbindung von Rechnern, Druckern und Servern an Macintosh-Rechner (shared resources). Dabei wird AppleTalk in drei Netzwerkkonfigurationen eingesetzt:
v als Stand Alone LAN mit bis zu 32 Knoten, das sog. LocalTalk
v als Internet mit Brücken und Gateways
v als Peripheriebus (AppleBus), z.B. für den Anschluß eines Druckers
Die Implementierung des AppleTalk wurde von einer Netzwerk-Philosophie geleitet:
∑ Mit AppleTalk sollte nach dem Grundsatz von „Good Performance At Low Cost“ ein leistungsfähiges Netzwerk zu einem günstigen Preis entstehen. Das kann nur erreicht werden, wenn keine teure Hardware und insbesondere keine spezielle Kommunikationskarte verwendet wird. AppleTalk ist in der Anschaffung wesentlich günstiger als vergleichbare Netzwerke.
∑ AppleTalk wurde als „Plug and Play“-Netzwerk konzipiert. Das heißt, die gesamte für die Kommunikation notwendige Hardware und Software ist im Rechner vorhanden. Es müssen nur noch die einzelnen Knoten über ein Kabel verbunden werden. Für den Benutzer muß das Netzwerk einfach zu handhaben und zu installieren sein. Dazu ist es notwendig, daß das Netz sich weitgehend passiv und selbstkonfigurierend verhält.
∑ Unter Minimierung der Codegröße und Komplexität sollte eine Steigerung der Leistungsfähigkeit erzielt werden. Durch eine Strukturierung nach dem OSI-Modell wurde eine offene und flexible Netzwerkarchitektur geschaffen, die nicht für einen speziellen Zweck konzipiert wurde. Die Hard- und Software basiert auf einer Bustopologie. Insbesondere nutzen die Protokolle die Broadcast-Fähigkeit eines Busses für Verwaltungszwecke.
AppleTalk besteht zu einem geringen Teil aus Hardware (dem Kommunikationsbaustein und einem Kabel mit Induktionskopplungen). Der überwiegende Teil von AppleTalk ist Software, die anhand des ISO/OSI-Modells in die Schichten 2–7 eingeordnet werden kann. Dabei befinden sich die Protokolle der Schichten 2–3 vollständig und die der Schicht 4 teilweise im ROM des Macintosh und werden bereits mit dem Gerät geliefert.
4.2.1 Aufteilung in Schichten und Protokolle
AppleTalk wurde nach dem OSI-Schichtenmodell entworfen. In jede OSI-Schicht lassen sich Protokolle mit den unterschiedlichsten Aufgaben einordnen. Die unterste, die physikalische Schicht bildet die AppleTalk-Hardware, ein zweidrahtiges Kabel, das über Induktionskopplungen abgegriffen wird.
Die darüberliegende Verbindungsschicht ist durch das AppleTalk Link Access Protocol (ALAP) realisiert, das für die Übertragung von Paketen von Knoten (Node) zu Knoten, die Zugriffskontrolle auf die Hardware und die dynamische Node-Adressierung verantwortlich ist. Für unterschiedliche physikalische Schichten, wie zum Beispiel die Ethernet-Hardware oder die normale Telefonleitung, existieren verschiedene Link Access-Protokolle[14].
Das Datagram Delivery Protocol (DDP) der Netzwerkschicht ist für die Übertragung von Datagrammen an die logischen Adressen in den Geräten, den sog. Sockets, eines Netzwerkes verantwortlich. Es bedient sich dabei der Dienste des ALAP.
Abb. 4.2.1: AppleTalk-Protokolle im ISO-Schichtenmodell
Auf der Transportschicht des AppleTalk befinden sich mehrere Protokolle mit unterschiedlichen Aufgaben. Die wichtigsten dabei sind das AppleTalk Transaction Protocol (ATP) und das Name Binding Protocol (NBP). Das ATP ist für die gesicherte Übertragung von Paketen verantwortlich. Das NBP dient der Zuordnung von Gerätenamen, Gerätetyp und Zonenbezeichnung zu Socket- und Netzwerkadresse. Die Verwaltung von Weglenkungstabellen in AppleTalk-Brücken übernimmt das Routing Table Maintenance Protocol (RTMP). Als Klient des DDP wird es der Transportschicht zugeordnet. Neu ist ein Echo Protocol (EP) zum Testen von Verbindungen und zur Bestimmung der Übertragungszeit zwischen zwei Knoten. Alle Protokolle der Transportschicht sind Klienten des DDP.
Über der Transportschicht ist die Session-Schicht angeordnet. Auch hier befinden sich mehrere Protokolle mit den verschiedensten Aufgaben (siehe Abb. 4.2.1). Ein Zone Information Protocol (ZIP) dient dazu, von einer AppleTalk-Brücke die Namen und Adressen weiterer Zonen anzufordern. Das Print Access Protocol (PAP) ermöglicht das Drucken über AppleTalk. Relativ neu ist das AppleTalk Session Protocol (ASP); es dient dem Aufbau, dem Abhalten und dem Abbrechen einer Session. Über das ASP kann eine Workstation Kommandos an einen Server leiten. Der Server antwortet mit Statusmeldungen oder den angeforderten Daten.
Das AppleTalk Filing Protocol (AFP) der darüberliegenden Präsentationsschicht ermöglicht einer Workstation den Zugang zu Dateien eines Fileservers.
4.2.2 Implementierung der AppleTalk-Protokolle als Treiber
Ein Treiber ist eine Sammlung von Prozeduren, die einer Applikation eine Software-Schnittstelle für den Zugriff auf ein I/O-Gerät zur Verfügung stellt. Die einzelnen Protokolle des AppleTalk sind zu Treibern zusammengefaßt. Im Macintosh Protocol Package (.MPP) sind das ALAP, das NBP, das DDP und das RTMP untergebracht. Zusätzlich liegen Teile des NBP als eigene Resourcen (NBPC1 und NBPC2) vor. Das ATP ist als eigenständiger Treiber .ATP implementiert. Das ASP und die Workstation-Seite des AFP sind im Treiber .XPP enthalten.
In den neueren Modellen der Macintosh-Familie sind der .MPP- und der .ATP-Treiber im ROM enthalten. Befindet sich im System File oder System Folder allerdings eine neuere Version des .MPP oder des .ATP als im ROM, so wird beim Öffnen des Treibers die neue Version geladen. Zu diesem Zweck gibt es eine AppleTalk-Systemdatei mit der jeweils neuesten Version. Der .XPP-Treiber ist nicht im ROM enthalten.
Als Schnittstelle für seine Klienten stellt der .MPP-Treiber die Prozeduren Status, Control, Prime, Open und Close zur Verfügung. Alle ALAP-, NBP- und DDP-Funktionen des Treibers werden in Assembler über einen Control-Call mit passendem csCode als Parameter gerufen (vgl. Abb. 4.2.2).
lookupReply EQU 242 ;
This command queued to ourself
writeLAP EQU
243 ; Write out LAP
packet
detachPH EQU
244 ; Detach LAP
protocol handler
attachPH EQU 245 ; Attach LAP protocol handler
writeDDP EQU
246 ; Write out DDP
packet
closeSkt EQU 247 ; Close DDP socket
openSkt EQU 248 ; Open DDP socket
loadNBP EQU
249 ; Load NBP
command-executing code
lastResident EQU
249 ; Last resident
command
confirmName EQU
250 ; Confirm name
lookupName EQU
251 ; Look up name on
internet
removeName EQU
252 ; Remove name
from Names Table
registerName EQU
253 ; Register name
in Names Table
killNBP EQU 254 ; Kill outstanding NBP request
unloadNBP EQU
255 ; Unload NBP
command code
Abb. 4.2.2: Die csCodes der Control-Calls für den .MPP-Treiber
Der Pascal-Programmierer muß keine Control-Calls verwenden. Ihm steht ein Pascal-Interface, der sog. AppleTalk Manager, zur Verfügung. Durch Glueroutinen und geeignete Datenstukturen wird die Benutzung von AppleTalk wesentlich erleichtert. Zum Laden und Schließen des .MPP-Treibers dienen die beiden folgenden Funktionen:
FUNCTION MPPOpen: OSErr;
Diese Prozedur entspricht der Open-Prozedur
des .MPP-Treibers und prüft zunächst, ob der .MPP-Treiber nicht schon geladen
wurde und ob Port B nicht schon in Gebrauch (PortBUse) oder für
AppleTalk konfiguriert ist (SPConfig). Ist dies nicht der Fall, so lädt MPPOpen den .MPP in den
System-Heap, reserviert Platz für die lokalen Variablen, initialisiert diese,
konfiguriert den Port B für AppleTalk und installiert Interrupt Handler zur
Behandlung von SCC-Interrupts. Zusammen mit der dynamischen Node-Adressierung
werden zur Suche nach einer AppleTalk-Brücke zwei Datagramme vom Typ 5 und
Commando 1 (RTMPRequests) an alle Nodes gesendet. Falls eine Brücke im Netzwerk
existiert, liefert sie in einem RTMP Response-Paket ihre Netzwerkadresse
zurückliefert.
FUNCTION MPPClose: OSErr;
Diese Funktion entspricht der Close-Prozedur. Sie entfernt den Treiber aus dem System Heap und gibt den Speicher, den der .MPP belegt, frei. Dieser Aufruf sollte nie vom Benutzer erfolgen, da er das gesamte AppleTalk deaktiviert und nicht sicher ist, ob nicht ein weiterer Prozeß AppleTalk verwendet.
4.2.3 Schicht 1: Die physikalische Schicht
Das sichtbare Equipment von AppleTalk ist der AppleBus, das AppleTalk-Kabel. Es handelt sich dabei um ein zweidrahtiges, verdrilltes Kabel mit einer Abschirmung. Mit diesem Kabel lassen sich Distanzen bis zu 300 m überbrücken. AppleTalk-Kabel sind relativ zuverlässig. Einziges Ärgernis sind die relativ teueren und unzuverlässigen Mini DIN 8-Stecker.
Um Reflexionen durch Leitungsunterbrechung zu vermeiden, erfolgt der Signalabgriff über Induktionskopplungen. Diese Kopplungen ermöglichen das An- und Abklemmen von Knoten ohne eine Störung des Netzes. Falls sich kein Stecker in der Buchse einer Leitungskupplung befindet, wird durch einen Schalter ein Abschlußwiderstand aktiviert, der Reflexionen am Leitungsende verhindert.
Das Übertragungsmedium läßt sich durch ein Glasfaserkabel oder ein vierdrahtiges Telefonkabel, wie es von PhoneNet verwendet wird, ersetzen. Voraussetzung dazu ist natürlich, daß alle Funktionen der Standard-Hardware gewährleistet sind und die Schnittstelle zur Verbindungsschicht eingehalten wird.
AppleTalk verwendet ein HDLC-Rahmenformat, das durch einen leistungsfähigen Kommunikationsbaustein, den Zilog SCC[15] 8530, unterstützt wird. Der SCC erlaubt eine automatische Adreßerkennung. Zwischen diesen Baustein und den Port B sind RFI-Filter und ein RS422A-Leitungstreiber geschaltet[16]. AppleTalk kann ohne Probleme nur am Port B (Printerport) betrieben werden, da die Softwareschichten SPConfig und PortBUse für Port B verwenden.
Abb. 4.2.3: Die FM0-Kodierung von Bits bei AppleTalk
Die FM0-Kodierung
der zu übertragenden Bits (vgl. Abb. 4.2.3) ermöglicht dem SCC bei Selbsttaktung den Takt aus dem
ankommenden Signal zu entnehmen. Der SCC wird intern mit 3.672 MHz getaktet.
Bei 16-maligem Abtasten pro Bit ergibt sich daraus für AppleTalk eine
Übertragungsrate von 229.5 kBaud[17].
Die Signalisierung der Daten an der Schnittstelle erfolgt als Balanced Signalling nach der RS422A-Spezifikation. Diese hat gegenüber der sonst üblichen RS232C-Schnittstelle den Vorteil, daß sie wesentlich störsicherer ist. Eine symmetrische Signalisierung erlaubt eine bessere Isolierung gegenüber der Masse und ist unempfindlicher gegen Spannungsänderungen oder allgemeine elektromagnetische Störungen. Dadurch werden höhere Übertragungsraten und größere Distanzen möglich.
Auf dem AppleBus wird ein CSMA/CA-Algorithmus zur Regelung des Zugriffs verwendet. Für die Beobachtung der Leitung (Carrier Sense) besitzt der SCC ein Hunt-Bit, das die Übertragung eines Paketes anzeigt. Der Synchronisation von Stationen dient auch das Clock Missing-Bit, das den Verlust der Bitsynchronisation meldet.
4.2.4 Schicht 2: Das AppleTalk Link Access Protocol (ALAP)
Das AppleTalk Link Access Protocol stellt die unterste Softwareebene von AppleTalk dar. Das ALAP hat die Aufgabe Pakete zwischen physikalischen Adressen zu übertragen (Abb. 4.2.4). Es benutzt 8-Bit-Node-Adressen um eine möglichst leistungsfähige Knoten-zu-Knoten-Paketübertragung auf einem einzelnen AppleBus zu gewährleisten. Eine wichtige Aufgabe besteht darin, den Zugriff von verschiedenen Knoten auf das Netzwerk zu regeln. Jeder Knoten (Node) im Netz besitzt zur Identifizierung eine 8-Bit-Node-Adresse. Das ALAP gewährleistet, daß jeder Node eine eindeutige Knotenadresse (Node ID) im Netzwerk besitzt. Es übernimmt für seine Klienten das Übertragen von LAP-Rahmen über das Netz.
Abb. 4.2.4: AppleTalk-Knoten am AppleBus
Das ALAP kann mehrere Klienten in einem Gerät besitzen. Empfängt das ALAP ein Paket, so entscheidet der Interrupt Handler im ALAP, an welchen Klienten der Rahmen übergeben wird. Der Interrupt Handler liest den LAP-Typ des Rahmens und ruft den zugehörigen Protocol Handler, der den Rest des Paketes einliest und verarbeitet. An das Ende eines jeden LAP-Paketes ist eine CRC-Prüfsumme angehängt, durch die das ALAP erkennen kann, ob ein Paket unversehrt übertragen wurde.
4.2.4.1 Das LAP-Paketformat
Abb. 4.2.5: Das ALAP-Paketformat
ALAP überträgt Rahmen, die ohne CRC mindestens 3 Bytes umfassen und maximal 603 Bytes lang sein dürfen. Im Normalzustand der Leitung (Idle) werden keine Signale übertragen. Vor der Übertragung eines Rahmens sendet das ALAP eine Sequenz von mindestens zwei Flags (01111110), die Frame Preamble zur Synchronisation mit dem Empfänger[18]. Über ein RTS-Paket vor dem eigentlichen Datenpaket nimmt der Sender zur Gegegenstation Verbindung auf. Ist die Gegenseite nicht erreichbar oder hat eine Kollision stattgefunden, so wird keine Antwort in Form eines CTS-Paketes erhalten. Andernfalls wird der ALAP-Rahmen übertragen. Abgeschlossen wird der Rahmen durch ein Flag und eine Abbruchsequenz von mindestens sieben 1-Bits. Ein ALAP-Rahmen besteht aus dem Header, dem Datenfeld und einer zwei Byte langen Prüfsumme (Abb. 4.2.5). Der Header enthält die Zieladresse, die Quelladresse und den LAP-Pakettyp. Das Datenfeld ist variabel lang (0–600 Bytes).
4.2.4.2 Pakettypen und dynamische Node-Adressierung
LAP-Pakete können verschiedenen Typs sein. Es gibt Kontroll- und Benutzerpakete. Die Typen 1–127 repräsentieren Pakete eines Klienten des LAP. Die Pakettypen 1 und 2 beansprucht das Datagram Delivery Protocol (DDP). Der Bereich von 128–255 ist für die Kontrollpakete des LAP reserviert. ALAP verwendet Kontrollpakete des Typs $81 (ENQ-Paket), $82 (ACK-Paket), $84 (RTS-Paket) und $85 (CTS-Paket).
Jeder AppleTalk-Node besitzt eine eindeutige 8-Bit-Adresse, die einem Node aber nicht fest für alle Zeiten zugeordnet ist, sondern dynamisch vereinbart wird. Der Hauptgrund dafür liegt darin, daß ein Node zwischen zwei AppleTalk-Netzen bewegt werden kann. Dabei kann der Fall eintreten, daß schon ein Node mit derselben Adresse im Netz existiert.
Normalerweise wird die Node-Adresse im Parameter RAM gehalten und nur, wenn sie nicht mehr vorhanden ist oder es im Netz einen Node mit derselben Adresse gibt, durch einen Zufallswert ersetzt. Jedesmal, wenn der .MPP-Treiber mit MPPOpen geöffnet wird, prüft die LAP-Prozedur AcquireAddress, ob die Node ID des Knotens im lokalen AppleTalk-Netz eindeutig ist. Das geschieht, indem der Node mehrmals hintereinander sog. Enquiry Control Frames an seine eigene Node-Adresse schickt und auf einen Acknowledge Control Frame wartet (Abb. 4.2.6).
Abb. 4.2.6: Die dynamische Node-Adressierung über den ENQ/ACK-Mechanismus
Erhält der Node ein ACK-Paket, so gibt es bereits einen Knoten mit dieser Adresse im Netz und es muß per Zufallsgenerator eine neue Adresse ermittelt werden. Erst wenn nach 200 ms kein ACK-Paket empfangen wurde, ist die Node ID eindeutig. Dem Benutzer stehen dabei die Werte 1–127 zur Verfügung. Der Bereich von 128 bis 254 ist für Server-Nodes reserviert. Der Wert 0 ist eine ungültige Node-Adresse und der Wert 255 ist für Broadcast-Pakete reserviert.
4.2.4.3 Medium Access Control im ALAP
Um die Kollision von Paketen auf der Leitung erkennen und vermeiden zu können, besitzt das ALAP einen Carrier Sense Multiple Access/Collision Avoidance-Algorithmus (CSMA/CA), welcher den Zugriff auf die Hardware kontrolliert.
Abb. 4.2.7: RTS und CTS-Pakete für den CSMA/CA-Algorithmus
Zuerst beobachtet der Sender eines Paketes die Leitung (carrier sense)[19]. Ist sie 400 ms (Inter-Dialogue Gap, IDG) frei, so wird eine zufällige Zeit (TR) gewartet und danach noch einmal geprüft[20]. Ist die Leitung immer noch frei, so wird an den Empfänger der Nachricht ein Request-to-Send-Paket (RTS) geschickt. Hat die Gegenstation das RTS-Paket erhalten und ist sie zur Entgegennahme eines Paketes bereit, so antwortet sie innerhalb von 200 ms (Inter-Frame Gap, IFG) mit einem Clear-To-Send-Paket (Abb. 4.2.7). Hat der Initiator das CTS-Paket erhalten, so beginnt er das Datenpaket zu schicken. Beginnen zwei Stationen gleichzeitig zu senden, so kollidieren ihre RTS-Pakete und gehen verloren (vgl. Abb. 4.2.7). Da die Empfänger kein korrektes RTS-Paket erhalten, werden sie auch nicht antworten und die Sender erhalten innerhalb von IFG kein CTS-Antwortpaket. Nach einer zufälligen Zeitspanne versuchen beide Stationen erneut zu senden, wobei eine der Stationen mit hoher Wahrscheinlichkeit Erfolg haben wird. Broadcast-Pakete werden gesendet ohne auf das CTS-Paket zu warten und oft mehrmals wiederholt.
4.2.4.4 Gewährleistung der Paketintegrität
Die Unversehrtheit eines Paketes läßt sich an der Länge und einer Prüfsumme erkennen:
Die Länge eines emfangenen Paketes muß der zusammen mit den Daten übertragenen Länge entsprechen. Letztere ergibt sich aus dem Inhalt der ersten zwei Datenbytes eines Paketes (DDP-Header) und der Länge des LAP-Headers (3 Bytes). Sie muß im Bereich von 3 bis 603 Zeichen liegen. Um fehlerhaft übertragene Pakete zu erkennen, wird dem Datenfeld des ALAP-Paketes eine 16-Bit-Prüfsumme angehängt. Diese errechnet sich aus dem Packet Header und dem Datenfeld. Die Verschlüsselung geschieht nach der CCITT-CRC-16-Empfehlung und verwendet das Polynom
G(x) = x16+x12+x5+1.
Der SCC von Zilog bietet im HDLC-Mode die Möglichkeit zur Berechnung und Überprüfung der CRC an. Signalisiert der SCC das Ende eines Paketes, so kann anhand des Frame Valid-Bits die Korrektheit der Prüfsumme erkannt werden. Weitere mögliche Fehler sind ein Frame Type-Error und ein Overrun/Underrun-Error.
4.2.4.5 Low Level-Routinen
Zu den Low Level-Routinen des ALAP zählen Prozeduren, die direkt auf die Hardware zugreifen und nach außen hin nicht sichtbar sind. Die wichtigsten Prozeduren sind AcquireAddress, ReadPacket, ReadRest und WritePacket. Die Funktion von AcquireAddress wurde in 4.2.4.2 beschrieben. Die Prozeduren ReadPacket und ReadRest werden von Protocol Handlern gerufen, um einen Teil oder den Rest eines Paketes einzulesen. Zu beachten ist, daß als letztes die Prozedur ReadRest gerufen werden muß, da sie Interrupts wieder zuläßt. Die Prozedur WritePacket sendet ein LAP-Paket. Weiter gibt es noch einen Interrupt Handler, der je nach LAP-Typ eines Paketes den zugehörigen Protocol Handler ruft. Als Schnittstelle zur Hardware stehen noch eine Reihe weiterer Hilfsprozeduren[21] zur Verfügung.
4.2.4.6 Receive-Interrupts und Protocol Handler
Um Pakete entgegenzunehmen, besitzt das ALAP einen Interrupt Handler. Entdeckt der SCC ein Paket, das an diesen Node adressiert ist, so fordert er beim Prozessor einen Interrupt an, um zu melden, daß Daten angekommen sind. Hierauf liest der Interrupt Handler die ersten 5 Byte aus dem SCC und legt sie in einem 24 Byte großen Zwischenpuffer, der Read Header Area (RHA), ab. Anhand des dritten Bytes des LAP-Paketes kann der Interrupt Handler entscheiden, welchen Protocol Handler er zu rufen hat (Abb. 4.2.8). Die LAP-Protokolltypen 1 und 2 sind dabei für die statischen Protocol Handler des DDP, die Typen 128 bis 255 für ALAP-Kontrollrahmen reserviert. Dynamische Protocol Handler werden über die Prozedur LAPOpenProtocol mit ihrer Codeadresse und ihrem Typ in die Protocol Handler Table eingetragen.
Abb. 4.2.8: Protocol Handler und Socket Listener im .MPP-Treiber
Das weitere Einlesen übernimmt ein dem LAP-Typ entsprechender Protocol Handler, indem er die Prozeduren ReadPacket und ReadRest ruft. Die Anzahl der Bytes, die noch zu lesen sind, steht im vierten und fünften Byte des Paketes (DDP-Header). Ein Receive-Interrupt muß sofort behandelt werden und das Einlesen muß schnell geschehen, da andernfalls der drei Byte große FIFO-Puffer des SCC überläuft. Der Protocol Handler hat ungefähr 95 µsec Zeit, um das Lesen des nächsten Zeichens durch die Prozeduren ReadPacket und ReadRest zu veranlassen. Bei einer Übertragungsrate von 64 kBaud steht damit rund 3–4 mal soviel Zeit zur Verfügung[22].
4.2.4.7 Die ALAP-Prozeduren
Die Funktionen des ALAP können von den Klienten durch folgende Pascal-Schnittstellen gerufen werden. Zu jeder Prozedur gibt es sowohl Pascal- als auch Assembler-Aufrufe.
FUNCTION LAPOpenProtocol(theLAPType: ABByte; protoPtr:Ptr):OSErr;
Durch diese Funktion wird zu einem LAP-Pakettyp der zugehörige Protocol Handler in die Protocol Handler-Tabelle eingetragen. Der Parameter theLAPType gibt den LAP-Typ an, bei dem dieser Protocol Handler aufgerufen wird. ProtoPtr ist ein Zeiger auf den neuen Protocol Handler.
Wird als protoPtr der Wert NIL angegeben, so installiert der AppleTalk Manager den Default Protocol Handler, um Pakete mit dem angegebenen LAP-Typ einzulesen. In diesem Fall muß die Prozedur LAPRead benutzt werden, um ein Paket einzulesen. Zeigt protoPtr jedoch auf den eigenen Protocol Handler, so liegt die Verantwortung für den korrekten Empfang bei diesem und die Prozedur LAPRead muß nicht gerufen werden. In Assembler läßt sich die Funktion von LAPOpenProtocol mit attachPH erreichen.
FUNCTION LAPCloseProtocol(theLAPType: ABByte):OSErr;
Entfernt einen Protocol Handler mit dem LAP-Typ theLAPType aus der Protocol Handler-Tabelle (Assembler: detachPH).
FUNCTION LAPWrite(abRecord: ABRecHandle; async: Boolean):OSErr;
Diese Prozedur sendet ein Paket an einen Node im lokalen Netzwerk. Die Zieladresse, der LAP-Typ, die Länge der Daten[23] und ein Zeiger auf die Daten werden in abRecord übergeben. Der Assembler-Programmierer muß die Informationen über das zu sendende Paket in einer Write Data Structure[24] (WDS) des ALAP ablegen. Im Parameterblock ParamBlockRec des Device Manager Control-Calls muß der csCode für writeLAP und der Pointer auf die WDS übergeben werden.
FUNCTION LAPRead(abRecord: ABRecHandle; async: Boolean):OSErr;
Mit LAPRead wird eine Paket eines bestimmten Pakettyps gelesen. Die Felder lapReqCount und lapDataPtr in abRecord geben die Größe und die Adresse des Puffers an, welcher die Daten aufnimmt. Ist dieser Puffer zu klein, um alle ankommenden Daten aufzunehmen, so wird der Rest des Paketes verworfen und die Meldung buf2smallErr zurückgegeben. Die Anzahl der empfangenen Bytes steht nach dem Aufruf im Feld lapActCount. Es werden nur Pakete entgegengenommen, deren LAP-Typ mit dem im Feld lapAddress.lapProtType übereinstimmt. Dabei sollte als LAP-Typ nur der eines zuvor geöffneten Protocol Handlers angegeben werden. In Assembler gibt es keine spezielle Read-Prozedur über einen Standard Protocol Handler. Will ein Assembler-Programmierer LAP-Pakete lesen, so muß er zuvor seinen eigenen Protocol Handler implementieren und in der Protocol Handler Table installieren.
Die LAP-Prozeduren bedienen sich weiterer Low-Level-Prozeduren, WritePacket, ReadPacket, ReadRest, und der SCC-Prozeduren, um über die AppleTalk-Hardware Pakete zu übertragen. Diese Prozeduren werden von den sichtbaren LAP-Prozeduren und den Protocol Handlern benutzt und können nicht über das Pascal-Interface des AppleTalk Managers gerufen werden.
4.2.5 Schicht 3: Das Datagram Delivery Protocol (DDP)
Auf der Netzwerkschicht des AppleTalk befindet sich das Datagram Delivery Protocol. Es übernimmt den Datagrammservice und die Handhabung von Internet-Paketen.
4.2.5.1 Die Aufgaben des DDP
Das DDP ist ein einfaches Protokoll, das eine Übertragung von Datagrammen zwischen logischen Adressen auf einem Netzwerk aus mehreren Teilbereichen (Zonen) erlaubt. Diese Socket-to-Socket-Übertragung kann sowohl zwischen Stationen im lokalen Netzwerk als auch über Brücken auf einem Internet stattfinden. Das DDP-Protokoll legt die Zieladresse der Datenpakete fest und erstellt eine geeignete Adreßpräambel für den Transport über die Teilstrecken eines Netzes. Dabei bedient es sich der Funktionen des ALAP, um Datagramme zu übertragen.
Abb. 4.2.9: Sockets in dem AppleTalk-Knoten am Bus
Kommen Datagramme beim Empfänger an, so übernimmt der Protocol Handler des DDP mit dem LAP-Typ 1 die lokalen, kurzen und der Protocol Handler vom Typ 2 die langen, Internet-weiten Frames. Die Struktur des DDP ist auf höchste Leistungsfähigkeit bei einfacher Struktur ausgelegt. Verlorene Pakete werden nicht erkannt und es findet keine Wiederholung verlorener Pakete statt. Optional kann den Datagrammen eine zusätzliche Prüfsumme zur Erkennung von fehlerhaft bearbeiteten Paketen in Brücken angefügt werden.
4.2.5.2 Sockets und Socket Listener
Sockets sind logisch adressierbare Einträge in Netzwerkknoten, die durch eine 8-Bit-Socket-Nummer identifiziert werden (vgl. Abb. 4.2.9). Dabei ist es möglich, mehrere logische Adressen (Socket-Nummern) pro physikalischer Adresse zu vereinbaren. Eine Socket-Nummer muß innerhalb eines Knotens stets eindeutig sein. Maximal können in einem Knoten 254 Sockets vereinbart werden. Datagramme sind Pakete, die zwischen Sockets durch den Datagram Delivery-Mechanismus ausgetauscht werden.
An jeden Socket ist ein Socket Listener (Klient) gebunden. Ein vom Protocol Handler 1 empfangenes Paket wird an einen Socket Listener mit der passenden Socket-Nummer übergeben. Ein Socket Listener ist ein Prozeß, der ein Datagramm entgegennimmt und verarbeitet. Die Zuordnung von Socket-Nummer und Socket Listener wird in der Socket Table vorgenommen.
Abb. 4.2.10: Sockets in einem Node
Es gibt zwei Typen von Socket(-Listener)s. Die statisch vereinbarten Sockets (1–64) sind reserviert für die Standard-Protokolle des AppleTalk. Die Sockets 65–127 sind zum „Experimentieren“ gedacht. Durch Klienten dynamisch vereinbart werden Sockets mit den IDs 128–254. Das NBP verwendet den Socket 2, ATP den Socket 3, RTMP Socket 1, das EP den Socket 4 und das DSP den Socket 5.
4.2.5.3 Das DDP-Paketformat
Das DDP kennt zwei verschiedene Pakettypen: lange und kurze Pakete. Kurze Pakete werden zwischen Sockets auf einem lokalen Netzwerk ausgetauscht. Lange Pakete dagegen dienen der Übertragung von Daten über Brücken hinweg, und enthalten zusätzliche Informationen über das Zielnetzwerk[25].
Abb. 4.2.11: Kurze und lange DDP-Pakete
4.2.5.4 Die DDP-Funktionen und ihre Aufgaben
Die folgenden DDP-Prozeduren sind für die Anpassung an ISDN zunächst ohne Bedeutung und werden nur der Vollständigkeit wegen erwähnt:
FUNCTION DDPOpenSocket(VAR theSocket: Byte; sktListener:Ptr): OSErr;
Diese Funktion entspricht dem Assembler-Aufruf openSkt und fügt eine Socket-Adresse und einen Zeiger auf den zugehörigen Socket Listener in die Socket Table ein.
FUNCTION DDPCloseSocket(theSocket: Byte): OSErr;
Mit dieser Prozedur läßt sich ein Socket wieder aus der Socket-Tabelle entfernen. Der Pascal-Aufruf entspricht der Assembler-Prozedur closeSkt. Ist kein passender Socket vorhanden, so wird ein Fehler zurückgegeben.
FUNCTION DDPWrite(abRecord:ABRecHandle; doCheckSum:BOOLEAN; async:BOOLEAN): OSErr;
Diese Funktion überträgt ein Paket an einen Socket. Die Felder des abRecord enthalten die Parameter der Übertragung. Über den Parameter doCheckSum ist es möglich, eine zusätzliche Checksumme zu einem Paket errechnen zu lassen. Der Ziel-Socket darf sich auch im selben Node wie der Quell-Socket befinden (Intra Node Delivery). In Assembler geschieht die Übertragung mit dem Aufruf writeDDP. Dabei muß ein Zeiger auf die Write Data Structure des DDP übergeben werden, welche die Parameter und Daten der zu übertragenden DDP-Pakete enthält (siehe Abb. 4.2.12).
Abb. 4.2.12: Write Data Structure für das DDP
FUNCTION DDPRead(abRecord: ABRecHandle; retCksumErrs: Boolean; async: Boolean): OSErr;
Mit DDPRead kann ein Datagramm von einem anderen Socket empfangen werden. Eine spezielle ReadDDP-Prozedur gibt es in Assembler nicht! Um DDP-Pakete zu lesen, muß der Assembler-Klient seinen eigenen Socket Listener installieren.
FUNCTION DDPRdCancel(abRecord: ABRecHandle): OSErr;
Mit dieser Funktion kann ein mit DDPRead initiierter, pendenter Lesevorgang abgebrochen werden.
4.2.6 Schicht 4: Das Name Binding Protocol (NBP)
Eines der wichtigsten Protokolle der Transportschicht ist das Name Binding-Protokoll. Das Name Binding bewirkt eine Abstraktion von Netzwerkadressen zu Namen und bedient sich der Dienste des DDP.
4.2.6.1 Die Aufgaben des Name Binding Protocols
Namen sind sehr viel einprägsamer und weniger variabel als Ziffern oder Adressen. Daher wurde in AppleTalk ein Name Binding Protocol zur Zuordnung von Namen zu Socket-Adressen integriert. Somit erhalten Prozesse, die an Sockets gebunden sind, Namen.
Protocols Use Addresses, People Prefer Names
Das NBP unterhält für jeden Knoten eine
eigene Tabelle mit Namen und Adressen, die dynamisch vereinbart werden. Die
Funktionen des NBP erlauben es, neue Namen zu Socket-Adressen in der Names
Table einzutragen, wieder zu löschen, nach Einträgen zu suchen und deren
Eindeutigkeit zu prüfen. Die Funktionen des NBP werden beispielsweise vom
Chooser-Deskaccessory verwendet, um nach Geräten auf dem Netzwerk zu suchen[26]. Ein Beispiel für die Auswahl eines benannten Gerätes über den
Chooser zeigt Abbildung 4.2.13.
Abb. 4.2.13: Der Chooser
Durch einen Name LookUp wird auf einem Netz nach der Netzwerkadresse zu einem Gerätenamen und -typ gesucht. Dabei werden sog. LkUp-Pakete an alle Nodes eines Netzwerkes gerichtet. Findet ein Knoten einen passenden Eintrag in seiner Names Table, so antwortet er mit einem LkUpReply-Paket. Hierzu benutzt das NBP als DDP-Klient den sog. Name Information Socket (NIS) mit der Socket-Nummer 2. Ein NBP-Klient kann über Wildcards auch mehrere Typen oder Namen anfordern.
4.2.6.2 Names Table-Einträge und Namen
Ein Eintrag in der Names Table einer Node mit Namen und Adresse wird NBP-Tupel genannt. Die Gesamtheit der Names Tables in einem Netz wird als Names Directory bezeichnet. Namen setzen sich zusammen aus Object-, Typ- und Zonen-String.
< Object >.< Typ
>.< Zone >
Jeder dieser Strings kann bis zu 32 Zeichen lang sein. Bei der Suche nach Namen auf einem Netzwerk können Wildcards verwendet werden. Ein '='-Zeichen steht hier für alle Typen und Namen. Ein Stern „*“ bedeutet, daß Geräte in dieser Zone gesucht werden. So liefert ein Name LookUp mit dem Tupel '=.=.*' alle benannten Einträge, die auf diesem Netz bekannt, d.h. in den Names Tables aller Knoten auf dem Netz vorhanden sind. Ein Eintrag in der Names Table hat folgende Form:
Abb. 4.2.14: Einträge im Names Table des NBP
Ein Zeiger auf den Anfang dieser Liste befindet sich in den lokalen .MPP-Variablen, auf die die globale Betriebssystemvariable ABusVars zeigt[27]. Der Offset innerhalb der .MPP-Variablen ist bei den jeweiligen Macintosh-Modellen verschieden und deshalb nicht dokumentiert. Ein Namen in der Names Table hat in Pascal die folgende Form:
EntityName = RECORD
objStr: Str32;
typeStr: Str32;
zoneStr: Str32;
END;
EntityPtr = ^EntityName;
Abb. 4.2.15: Die Struktur eines Entity-Namens
Der Speicherplatz für einen Eintrag wird vom jeweiligen Klienten des NBP gestellt und liegt somit normalerweise im Application Heap. Dieser Heap wird vom Memory Manager beim Verlassen des Programmes geleert. Daher sollte eine Applikation ihre Einträge zuvor aus der Names Table entfernen. Wird das vergessen, so sorgt ein spezieller Mechanismus dafür, daß der Eintrag entfernt wird[28].
4.2.6.3 Das NBP-Paketformat
Es gibt drei verschiedene Typen von NBP-Paketen. Alle benutzen denselben DDP-Protokolltyp 2. Das LkUp-Paket dient der Suche nach Einträgen. Das LkUpReply-Paket enthält die Antworten der einzelnen Nodes auf ein LkUp-Paket. Die BrRq-Pakete werden beim Name LookUp über AppleTalk-Brücken verwendet. Enthalten ist die Typenbezeichnung im ersten Nibble Control des NBP-Rahmens. Das zweite Nibble tuple count gibt an, wieviele Einträge (Tupel) das Paket enthält. LkUp- und BrRq-Pakete enthalten stets genau ein Tupel. Wurde das LkUp-Paket mehrfach gesendet, so dient die NBP ID der Zuordnung des LkUpReply-Paketes zum entsprechenden LkUp-Paket. Das zum LkUp-Paket gehörende LkUpReply-Paket enthält dieselbe NBP ID.
Abb. 4.2.16: Das Format eines NBP-Rahmens und eines NBP-Tupels
Ein NBP-Tupel besteht aus dem Namen eines Eintrags und dessen 4-Byte-langer Adresse (Netzwerk-Nummer, Node ID und Socket-Nummer), sowie einer laufenden Nummer von einem Byte Länge. Diese Nummer ist notwendig, um den Fall, daß mehrere Einträge denselben Socket benutzen, zu handhaben. Anschließend folgt der Gerätenamen aus je einem String für Name, Typ und Zone (Abb. 4.2.16). Jeder dieser Strings wird angeführt von einem Längenbyte und ist maximal 32 Zeichen lang. Es gibt kein Trennzeichen zwischen den Strings.
4.2.6.4 Die NBP-Funktionen
Das Name BindingProtocol stellt Funktionen zur Installation des NBP-Codes, zur Registrierung von benannten Einträgen und zur Suche nach solchen auf dem Netzwerk zur Verfügung:
FUNCTION NBPLoad: OSErr;
Das NBP wird normalerweise zusammen mit dem .MPP in den Application Heap geladen. Lediglich beim Macintosh 128K muß das gesondert geschehen. Bei neueren Macintosh-Rechnern haben diese Prozeduren keine Wirkung.
FUNCTION NBPUnLoad: OSErr;
Durch diesen Aufruf wird der NBP-Code „purgeable“ gemacht, d.h. das System kann das NBP aus dem Heap entfernen, sobald es Speicher benötigt.
Die folgende Prozeduren dienen der Verwaltung der Names Table in einem Node und der Suche nach Einträgen in anderen Nodes:
FUNCTION NBPRegister(abRecord: ABRecHandle; async: Boolean): OSErr;
Diese Funktion fügt der Names Table eines Nodes einen neuen Eintrag hinzu, sollte er noch nicht auf dem Netzwerk vorhanden sein. Im Feld nbpAddress muß die vollständige Netzwerkadresse angegeben werden, unter der der Name registriert werden soll. Ist der Zonenname unbekannt, so sollte stets '*' verwendet werden. Eine Registrierung läuft wie folgt ab:
v Zuerst wird mit einem LkUp-Paket ($21) an alle Stationen[29] auf dem Netz nach dem zu registrierenden Eintrag gesucht:
FF 27 01 00 1B 02 AC 02 21 23 00 00 27 AC 00 03 .'......!#..'...
49 4E 46 08 4E 65 74 43 68 65 63 6B 01 2A INF.NetCheck.*
Abb. 4.2.17: Ein LkUp-Paket beim Name
Register-Call
v Erhält das NBP nach einer im abRecord vorgegebenen Anzahl von Versuchen keine Antwort, so nimmt es an, der Eintrag sei auf dem Netz noch nicht vorhanden und somit eindeutig. Der Eintrag kann in die Names Table eingetragen werden.
27 9E 01 00 1B AC 02 02 31 23 00 00 9E FA 01 03 .'......!#..'...
49 4E 46 08 4E 65 74 43 68 65 63 6B 01 2A INF.NetCheck.*
Abb. 4.2.18: Ein LkUpReply-Paket beim
Name Register-Call
Wird vom NBP im suchenden Knoten ($27) ein LkUpReply-Paket ($31) mit der zum LkUp-Paket passenden NBP ID[30] ($23) empfangen, so ist der Eintrag schon in einem Node vorhanden. Als Ergebnis im Feld abResult wird dann nbpDuplicate zurückgegeben.
FUNCTION NBPRemove(entityName: EntityPtr): OSErr;
Durch diesen Aufruf kann ein Eintrag wieder aus der Names Table gelöscht werden.
FUNCTION NBPLookUp(abRecord: ABRecHandle; async: Boolean): OSErr;
NBPLookUp liefert alle benannten Einträge mit dem gesuchten Namen auf dem Netzwerk. Das Feld nbpEntityName in abRecord ist ein Zeiger auf den gesuchten Namen. Das Ergebnis der Suche wird in einem Puffer abgelegt, auf den das Feld nbpBufptr zeigt. Im einzelnen läuft die Suche folgendermaßen ab:
v Zuerst wird die eigene Names Table durchsucht. Anschließend wird ein LkUp-Paket ($21) an alle Teilnehmer ($FF) der spezifizierten Zone geschickt.
FF 27 01 00 12 02 AC 02 21 24 00 00 27 AC 00 01 .'......!$..'...
3D 01 3D 01 2A =.=.*
Abb. 4.2.19: Ein LkUp-Paket zur Suche nach allen Einträgen auf dem Netzwerk
v Die Nodes im Netz liefern alle gefundenen Einträge, die der gesuchten Beschreibung (auch Wildcards) entsprechen, in LkUpReply-Paketen ($31) zurück.
27 9E 01 00 26 AC 02 02 31 24 00 00 9E FA 01 0B '...&...1$......
4C 61 73 65 72 57 72 69 74 65 72 0B 4C 61 73 65 LaserWriter.Lase
72 57 72 69 74 65 72 01 2A rWriter.*
27 BE 01 00 22 AC 02 02 31 24 00 00 BE FD 01 09 '..."...1$......
43 49 50 53 65 72 76 65 72 09 41 46 50 53 65 72 CIPServer.AFPSer
76 65 72 01 2A ver.*
Abb. 4.2.20: Die Antwortpakete auf das LkUp-Paket
Die erhaltenen Einträge werden in einem Puffer abgelegt.
FUNCTION NBPConfirm(abRecord: ABRecHandle; async: Boolean): OSErr;
Um zu prüfen, ob eine vorhandene Adresse noch gültig ist, wird ein LkUp-Paket direkt an die Node-Adresse eines Eintrags übertragen[31].
FUNCTION NBPExtract(theBuffer: Ptr; numInBuf: Integer; whichOne: Integer; VAR abEntity: EntityName; VAR address: AddrBlock): OSErr;
Um dem Puffer mit dem Ergebnis eines Name LookUps einen Eintrag zu entnehmen, steht dem Klienten der Befehl NBPExtract zur Verfügung. TheBuffer verweist dabei auf die Liste mit den Einträgen.
4.2.7 Schicht 4: Das AppleTalk Transaction Protocol (ATP)
Das wichtigste Protokoll der Transportschicht ist das AppleTalk Transaktion Protocol. Es nutzt die Fähigkeit des DDP, Sockets zu öffnen und über diese Datagramme zu übertragen. Eine AppleTalk-Transaktion findet statt, wenn ein Klient von einem Socket Anfragen (Requests) an einen anderen Socket sendet, auf die eine Antwort erfolgen muß. Diese Antwort kann entweder ein Statusbericht oder eine Bestätigung der angeforderten Anfrage sein. Durch das Koppeln von Anfrage und Antwort wird ein verlustfreier Transport von Information gewährleistet. Die sichere Übertragung von Paketen ermöglicht ein Datagram Loose Recovery-Algorithmus, der verlorene Pakete nach einer verstrichenen Zeitspanne wiederholt. Wurde nach einer bestimmten Anzahl von Retries immer noch keine Antwort erhalten, so wird die Transaktion abgebrochen. Über ein Bitmarkenprotokoll findet eine Flußkontrolle statt. Es ist möglich, mehrere Transaktionen gleichzeitig zu unterhalten.
4.2.7.1 Ablauf einer ATP-Transaktion
Die an einer Transaktion beteiligten Partner, die anfragende und die antwortende Station, werden Klient und Server genannt. Im folgenden wird angenommen, daß der Klient die Netzwerkadresse des Servers kennt. Eine Transaktion zwischen einem Klienten und einem Server läuft dann wie folgt ab[32]:
v Der Server öffnet mit dem Befehl ATPOpenSocket einen Responding Socket auf dem Netzwerk. Das ATP installiert automatisch einen Socket Listener für diesen Socket, der die Daten in einem nach der Buffer Description Structure (BDS) zuvor angelegten Puffer ablegt.
v Der Server ruft anschließend die Routine ATPGetRequest, die zurückkehrt, wenn ein Request-Datenpaket empfangen wurde.
v Der Klient ruft die Prozedur ATPSendRequest mit der Netzwerkadresse des Servers und bis zu 578 Bytes Anfragedaten in einem Puffer. Das ATP stellt sicher, daß diese Daten zum Server übertragen werden. ATPSendRequest wartet auf eine Antwort vom Server, die bis zu acht Datenpakete umfassen kann. Wurden nach einem Timeout nicht alle angeforderten Pakete erhalten, da etwa das TReq-Paket oder das TResp-Paket verloren oder verspätet ist, wird die Anfrage solange wiederholt, bis alle Daten angekommen sind oder die maximale Anzahl von Versuchen überschritten wird. Für die Dauer einer Transaktion wird von ATPSendRequest ein Socket geöffnet und nach Erhalt der Antwort selbständig wieder geschlossen, wovon der Benutzer des ATP nichts bemerkt.
v Der Server erhält das Request-Datenpaket und legt es in einem Puffer ab. ATPGetRequest kehrt zum Aufrufenden zurück, der dann mit ATPSndRsp die Antwort überträgt, die bis zu acht Puffer mit einem Inhalt von bis zu 578 Bytes umfassen kann. Die Antwort enthält auch wieviele Puffer (1 bis 8) insgesamt gesendet werden und welcher sich in einem bestimmten Paket befindet. Da das ATP mehrere Transaktionen gleichzeitig unterhalten kann, muß das Antwortpaket dieselbe Transaction ID (TID) wie das Anfragepaket enthalten. Der ATPSendRequest des Klienten unterhält eine Tabelle, in der über die empfangenen Pakete buchgeführt wird.
Abbildung 4.2.21 zeigt den Verlauf einer Transaktion, die von einem Server sechs Datenblöcke anfordert. Dabei geht ein Paket verloren und muß nach dem Ablauf eines Timeouts wiederholt werden.
Abb. 4.2.21: Datagram Loose Recovery des ATP
4.2.7.2 Weitere Eigenschaften des ATP
Das ATP unterstützt einige Spezialfälle von Transaktionen. Hierzu gehören die Exactly-Once Transactions (XO). Eine XO-Transaktion wird verwendet, wenn sichergestellt werden muß, daß eine Anfrage in einem Server nur einmal bearbeitet wird, da eine doppelte Bearbeitung Fehler verursachen würde. Kommt eine wiederholte Anfrage am Server an und der vorangegangene Request wird noch bearbeitet, so muß sie verworfen werden. Dieser Modus wird zum Beispiel vom PAP oder vom ASP verwendet. Durch die Beifügung eines Send Transaction Status (STS) zu einem Paket kann der Server bei Puffermangel beim Klienten nachfragen, welcher Teil der Antwort bei diesem angekommen ist. Darauf gibt der Server die nicht mehr benötigten Puffer frei.
4.2.8 Schicht 4: Das Echo Protocol (EP)
Das EP ist ein einfaches Protokoll, das es erlaubt zu testen, ob auf dem Netzwerk eine bestimmte Station unter einer Adresse erreichbar ist. Empfangene Pakete werden einfach an den Echo-Socket des Senders zurückgeschickt. Durch diesen Mechanismus ist auch eine Laufzeitbestimmung auf dem Netz möglich.
4.2.9 Schicht 4: Routing Table Maintenance Protocol (RTMP)
Dieses Protokoll stellt die Weglenkungsinformation zur Verfügung, die benötigt wird, um Datagramme über Brücken und Router hinweg zum Zielnetzwerk zu leiten. Für die Weglenkung werden in Brücken Tabellen benötigt, die über den Weg zu den Netzwerken Auskunft geben (Abb. 4.2.22). Aufgabe des RTMP ist die dynamische Verwaltung von Weglenkungstabellen in Brücken. Das RTMP muß Änderungen in der Netzwerkstruktur erkennen und die Tabelle entsprechend aktualisieren.
|
Netzwerk Nummer |
Entfernung |
Port |
Nächste Brücke/IR |
Status des Eintrags |
|
3 |
1 |
2 |
0 |
Good |
|
14 |
3 |
3 |
1131 |
Good |
|
23 |
2 |
3 |
753 |
Good |
|
27 |
1 |
2 |
753 |
Good |
Abb. 4.2.22: Ein Beispiel für die Weglenkungstabelle einer AppleTalk-Brücke
4.2.10 Schicht 5: Das AppleTalk Session Protocol (ASP)
Das ASP ist ein Klient des ATP und dient dem Aufbau, der Aufrechterhaltung und dem Abbau von Sitzungen an einem Server oder Host. Über eine Session werden Kommandos an einen Server gerichtet, der diese bearbeitet und die Resultate oder Daten zurücksendet. Über das ASP können Datenblöcke von der Workstation an einen Server übertragen werden. Durch einen Attention-Mechanismus kann die Workstation vom Server alarmiert werden. Diese kann vom Server Service-Status-Information anfordern, ohne eine Session eröffnen zu müssen. Die Funktionen des ASP ergänzen das ATP zu einem vollständigem Transportservice, sind aber von dieser Schicht unabhängig.
4.2.10.1 Sitzungen und Kommandos
Das ASP ist ein asymmetrisches Protokoll zum Abhalten von Sitzungen zwischen einem Server und einer Workstation. Da mehrere Workstations eine Sitzung an einem Server unterhalten können, wird für jede dieser logischen Beziehungen eine eindeutige Session ID verwendet. Eine Sitzung wird stets von der Workstation eröffnet, beendet werden kann sie von beiden Seiten.
Über eine Sitzung werden Kommandos von der Workstation an den Server gesendet, jedoch nicht umgekehrt. Das ASP gewährleistet, daß die Kommandos in der richtigen Reihenfolge zum Server gelangen und die Antworten richtig zurückgesendet werden. Es garantiert nicht für die Ausführung der Kommandos. Das ASP versteht keine Syntax und Semantik von Befehlen. Dafür sind die Klienten des ASP zuständig. Die Verwendung von ATP-XO-Transaktionen verhindert, daß Befehle mehrfach ausgeführt werden. Man kann dabei zwischen Kommandos und Schreibbefehlen unterscheiden.
v Kommandos werden als ATP-Request an den Server Session Socket (SSS) gerichtet, von einer höheren Schicht interpretiert und ausgeführt. Die Antwort wird als ATP-Response über das ASP und ATP übertragen.
v Schreibzugriffe von der Workstation zum Server müssen, da ATP-Transaktionen Daten nur jeweils in eine Richtung übertragen können, in zwei Schritten erfolgen:
1. Die Workstation schickt an den Server das Kommando sich die Daten zu holen.
2. Der Server sendet einen ATP-Request zur Workstation, die die Daten darauf als Response-Pakete zum Server überträgt.
4.2.10.2 Aufbau einer Sitzung
Stellt ein Server einen Dienst zur Verfügung und will eine Workstation diesen benutzen, so laufen folgende Aktionen ab:
v Ein Server bietet dem Netzwerk seinen Dienst an, indem er hierfür einen ATP-Responding Socket, den Session Listening Socket (SLS) installiert. Danach benutzt der Server das NBP, um einen Namen für diesen Socket zu registrieren. Anschließend ruft er das ASP, um diesem über einen SPInit-Befehl die Adresse des SLS mitzuteilen. Hierauf beginnt das ASP den SLS auf eine Open Session-Anfrage zu beobachten.
v Eine Workstation, die eine Sitzung mit diesem Server aufbauen will, verwendet nun das NBP, um auf dem Netzwerk nach dem Dienst und der Adresse des SLS zu suchen. Nun sendet sie ein Open Session-Paket als ATP-Request zum SLS des Servers. Dieses Paket enthält die Socket-Adresse des Workstation Session Socket, an den später die Session Maintenance-Pakete gerichtet werden.
v Der Server öffnet für jede neue Sitzung einen eigenen Socket, den Session Service Socket (SSS), und gibt im Response-Paket die Adresse dieses Sockets sowie die Session ID zurück. Alle weiteren Requests dieser Session an den Server enthalten diese Session ID und werden an den SSS gerichtet.
v Die Requests der Workstation sind an den SSS gerichtet, die Responses des Server an den WSS (Abb. 4.2.23). Eine Session kann von beiden Seiten abgebaut werden.
Abb. 4.2.23: Requests zwischen den ASP-Sockets
4.2.10.3 Session Maintenance
Ein Teilnehmer an einer Session muß stets wissen, ob die Gegenseite noch aktiv und erreichbar ist. Zu diesem Zweck wird von der Workstation und vom Server für die Dauer einer Session jeweils eine Transaktion mit unendlich vielen Wiederholungen, die Tickle Transaction, gestartet. Alle 30 Sekunden wird ein ATP-Request an die Gegenseite gerichtet. Hat ein Teilnehmer, aus welchen Gründen auch immer, 2 Minuten lang kein solches Paket erhalten, so nimmt er an, daß die Gegenseite nicht mehr aktiv ist und beendet die Sitzung[33].
4.2.11 Schicht 5: Das Zone Information Protocol (ZIP)
Dieses Protokoll unterstützt AppleTalk-Zonen, indem es die Zuordnung von Zonennamen zu Netzwerknummern übernimmt. Die dafür verwendeten Zoneninformationstabellen (ZIT) sind in allen Brücken zwischen den Netzwerken vorhanden und werden durch die Funktionen des ZIP verwaltet.
Abb. 4.2.24: Zusammenwirken des ZIP mit anderen Protokollen
Das ZIP wird vom NBP verwendet, um festzustellen, welches Netzwerk einer bestimmten Zone zugeordnet ist. Das ZIP wiederum bedient sich der Informationen des RTMP und der Funktionen des ATP und DDP (Abb. 4.2.24).
4.2.12 Schicht 5: Das Printer Access Protocol (PAP)
Das PAP-Protokoll wickelt den Dialog mit Drucker-Servern ab. Es übernimmt den Aufbau, die Verwaltung und den Abbau der Verbindung zum Drucker, sowie den Datentransfer. Für die Abwicklung eines Druckvorgangs werden die Dienste des NBP und des ATP beansprucht[34].
4.2.13 Schicht 5: Das AppleTalk Data Stream Protocol (ADSP)
Dieses Protokoll ist ein symmetrisches, verbindungsorientiertes Protokoll. Es erlaubt die Einrichtung und Aufrechterhaltung eines zuverlässigen, kontinuierlichen, duplikatfreien und sequenzerhaltenden Bytestrom zwischen zwei Sockets in einem AppleTalk-Netz. Das ADSP enthält zudem eine Flußkontrolle über einen Fenstermechanismus. Realisiert werden diese Eigenschaften des ADSP durch Sequenzunummern, die logisch mit den Datenbytes verbunden sind.
Das ADSP bietet dem Benutzer eine einfache, aber dennoch mächtige Schnittstelle zum AppleTalk-Netzwerk. Über das ADSP kann ein Klient eine Verbindung zu einem Kommunikationspartner eröffnen, Daten an die Gegenstelle senden und von dieser empfangen, und schließlich die Verbindung beenden. Ein Klient kann entweder einen kontinuierlichen Datenstrom übertragen oder die Daten logisch in Meldungen unterteilen, die vom Klienten der Gegenseite interpretiert werden. Das ADSP sieht auch einen Attention-Mechanismus für die interne Kontrolle der Klienten vor. Ein Forward-Reset-Mechanismus erlaubt einem Klienten, die Übertragung von ausstehenden Daten an den Klienten der Gegenseite zu unterbrechen.
4.2.14 Schicht 6: Das AppleTalk Filing Protocol (AFP)
Das AFP ist ein Klient des ASP und erlaubt einer Workstation den Zugriff auf die Dateien eines abgesetzten Diskservers[35]. Im .XPP-Treiber einer Workstation ist nur der Teil des AFP implementiert, den sie benötigt, um auf einen Server zuzugreifen. Das AFP arbeitet mit den Dateisystemen[36] verschiedener Rechner zusammen und ist erweiterbar für künftige Workstations. Über Paßwörter kann, ähnlich wie bei Unix, der Zugriff auf Server, Volumes und Directories kontrolliert werden.
4.2.14.1 Interpretation der Dateisystemkommandos
Greift eine Applikation auf eine Datei zu, so wird zuerst geprüft, auf welchem Volume diese Datei zu finden ist:
v Befindet sich die Datei auf einem lokalen Volume, so wird das Kommando durch das Native File System direkt ausgeführt.
v Befindet sich eine Datei jedoch auf einem Dateiserver, so werden die Kommandos an einen Translator gerichtet, der die NFS-Befehle in einen oder mehrere AFP-Befehle an den Server umwandelt und das Ergebnis der Operation wieder an das NFS übergibt.
Abb. 4.2.25: Umsetzung von Dateikommandos in AFP-Calls
Es gibt zwei Interfaces im Dateisystem, das Native Filing Interface (NFI), durch das Programme Dateidienste anfordern und das AppleTalk Filing Interface (AFI), über das der Translator AFP-Requests absetzt (Abb. 4.2.25). Das AFI besteht dabei aus folgenden Teilen:
v der AFP File System Structure, aus Servern, Volumes, Directories, Files und Forks,
v den AFP-Befehlen, die diese Struktur manipulieren, und
v den für die Details einer Manipulation verantwortlichen Algorithmen.
Der Translator hat dabei die Aufgabe, Anfragen durch das NFI als AFP-Requests durch das AFI zu transformieren und die Anforderungen der NFS-Befehle zu erfüllen. Ein Programm muß aber auch direkt auf das AFP zugreifen können, falls kein NFS-Äquivalent existiert.
4.2.14.2 Ablauf einer AFP-Session
Für den Aufbau einer Session am Server benutzt das AFP die Funktionen des ASP. Die Einrichtung einer AFP-Session stimmt daher, bis auf einige Besonderheiten des AFP, mit dem Aufbau einer ASP-Session weitgehend überein:
v Der Server registriert sich auf dem Netzwerk und eröffnet einen SLS.
v Die Workstation (WS) sucht mit '=.AFPServer.*' auf dem Netz nach Dateiservern und wählt den gewünschten Server aus.
v Die WS eröffnet eine Session durch einen FPLogin-Befehl, ähnlich wie beim ASP. Anschließend findet eine User-Authentisierung und eine Versionskontrolle statt.
v Kommandos werden von der WS zum Server übertragen. Dieser sendet die Resultate und Daten der Anfragen.
v Beim Ausloggen vom Server werden alle Daten der Session verworfen und die ASP-Session beendet.
4.2.14.3 AFP File System-Struktur
Die AFP File System-Struktur besteht aus Servern, Volumes, Directories, Dateien und Forks. Die Server eines Netzwerkes werden beim Öffnen einer Session angezeigt und der gewünschte Server ausgewählt. Für jeden Server ist es möglich ein gesondertes Icon, das auf dem Desktop[37] erscheint, zu definieren. Ein Server kann aus einem oder mehreren Volumes bestehen, auf die bei passendem Paßwort zugegriffen werden kann. Die Volumes sind analog zum hierarchischen Dateisystem des Macintosh in Directories und Pfade unterteilt. Eine Macintosh-Datei besteht aus einer Resource- und einer Datenfork. Greifen Systeme auf den Server zu, die dieses Konzept nicht unterstützen, so bleibt die Resource Fork einer angelegten Datei leer.
4.2.15 Schicht 7: Die Application Layer
Jedes Programm, das eine der Schichten 1–6 als Anwendungsprogramm nutzt, kann zu dieser Schicht gezählt werden. Ein schönes Beispiel ist das Programm NetTrek, das es ermöglicht „Raumschiff Enterprise“ über AppleTalk zu spielen. Ferner ist auf dieser Schicht jedes Programm zu finden, welches das Drucken von Dokumenten unterstützt.
4.2.16 Das Zusammenwirken der Protokolle
Zur Übertragung von Daten über AppleTalk bedient sich ein Klient der Protokolle des AppleTalk Protocol Stacks. Auf jeder Schicht wird den Nutzdaten dabei die für die Abwicklung des Datentransportes notwendige Steuerinformation beigefügt (Abb. 4.2.26).
Abb. 4.2.26: Das Verpacken eines Frames
Bei kurzen Paketen kann das zu einem beträchtlichem Protokolloverhead führen, da unter Umständen die Kontrollinformation länger ist als die Nutzdaten. Wandert ein Paket auf der Empfängerseite durch die Schichten nach „oben“, so wird die Steuerinformation einer jeden Schicht wieder entfernt.
Grundsätzlich versucht AppleTalk das Umkopieren von Paketen zu vermeiden, indem Zeiger auf Paketteile übergeben werden. Beim Senden setzt sich ein Paket aus den Einzelteilen der WDS zusammen. Die Steuerinformationen der Schichten werden als Teile der WDS angelegt. Beim Einlesen eines Paketes wird vom Klienten durch Zeigerübergabe ein Puffer bereitgestellt, in den die gewünschte Information direkt eingelesen wird. Jede Schicht liest dabei nur den Teil eines Paketes in ihren Puffer, den sie für die Bearbeitung und Weiterleitung des Paketes benötigt[38].
Abb. 4.2.27: Packet Handling in einem Knoten
Eröffnet zum Beispiel das AFP für einen Dateitransfer eine ASP-Sitzung, so werden zur Kontrolle der Sitzung ATP-Transaktionen (Tickle-Transaktion) gestartet. Für jede Transaktion wird dabei ein DDP-Socket geöffnet und nach Beendigung wieder geschlossen (Abb. 4.2.27). Das ATP installiert für jede Transaktion einen Socket Listener. Ankommende Datagramme werden vom DDP anhand einer Socket Table zu den entsprechenden Klienten übertragen, indem der zur Socket-Adresse des Paketes gehörende Socket Listener gerufen wird.
4.2.17 Der AppleTalk Manager
Der AppleTalk Manager[39] ist eine Sammlung von Glue-Routinen, die den Zugriff auf die AppleTalk-Treiber in Pascal erleichtert und die Verwendung der AppleTalk-Dienste wesentlich vereinfacht. Der Benutzer muß keine aufwendigen Device Manager Control-Calls für Treiber verwenden (Abb. 4.2.28). Dieses Interface erlaubt den Zugriff sowohl auf den .MPP- und .ATP- als auch auf den .XPP-Treiber.
Abb. 4.2.28: Der AppleTalk Manager
Der LAP Manager stellt dem Pascal-Programmierer einen Standard Protocol Handler und Socket Listener zur Verfügung. Das bedeutet eine erhebliche Erleichterung beim Zugriff auf AppleTalk. Will ein Assembler-Programmierer Pakete über AppleTalk empfangen, so muß er zuerst seinen eigenen Protocol Handler oder Socket Listener schreiben. Der AppleTalk Manager übernimmt außerdem über den Device Manager die Verwaltung von mehreren aufgesetzten Lesezugriffen.
Zusätzlich offeriert der AppleTalk-Manager geeignete Datenstrukturen und Konstanten für den Zugriff auf AppleTalk. Es müssen keine aufwendigen Device Manager Control- oder AppleTalk-Strukturen gehandhabt werden[40] (vgl. Abb. 4.2.29). Dieses Pascal-Interface ist Bestandteil der Bibliothek eines jeden Pascal-Compilers für den Macintosh und gehört nicht direkt zu AppleTalk. Es wird beim Linken einer Applikation zum Objektcode hinzugebunden.
WITH WriteABRecord^^ DO BEGIN
lapAddress.LapProtType:=34;
lapAddress.dstNodeID:=39;
lapReqCount:=dataLen;
lapDataPtr:=@Buffer;
END;
Abb. 4.2.29: Ein Beispiel für die zu übergebenen Parameter beim Schreibzugriff über den AppleTalk Manager
Obwohl der AppleTalk-Manager den Zugriff auf AppleTalk erheblich vereinfacht, bestehen dennoch viele Möglichkeiten, Fehler zu begehen. So ist beispielsweise darauf zu achten, daß bei einem asynchronen Schreibzugriff ein Datenblock nicht freigegeben wird, bevor er tatsächlich geschrieben wurde. Netzwerk-Applikationen müssen daher sehr sorgfältig durchdacht sein.
Bemerkenswert an der AppleTalk-Netzwerkarchitektur ist, daß sich auf den Schichten 2 und 3 einfache Protokolle mit wohldefinierten Schnittstellen befinden, die leicht zu substituieren sind. Indem die Protokolle des AppleTalk die Broadcast-Fähigkeit des Busses nutzen und Pakete multiplexen, nehmen sie implizit an, die physikalische Schicht zu kennen. So kann der Vorgang der dynamischen Node-Adressierung in einem leitungsvermittelnden Netz nicht wie im ALAP durchgeführt werden. Die gleichen Schwierigkeiten ergeben sich mit den Broadcast-Paketen anderer Protokolle.