5. Exemplarische Adaptionen
In diesem Abschnitt werden repräsentative Adaptionen von Rechnernetzen an unterschiedliche Übertragungsmedien und Topologien vorgestellt. Anhand von ausgewählten Beispielen wird aufgezeigt, welche Anpassungen vorzunehmen sind, wenn die Struktur oder das Übertragungsmedium eines Netzwerkes verändert wird.
Als vorbildliche Anpassung von LAN-Funktionen an eine leitungsvermittelnde Struktur gilt das PluriCom-Kommunikationspaket. Am Beispiel von AppleTalk werden unterschiedliche Methoden der Anpassung eines LAN an veränderte Topologien erörtert. Derartige Adaptionen beruhen vorwiegend wieder auf Bussystemen. Schließlich wird eine Anbindung von AppleTalk an Ethernet über einen Gateway vorgestellt und eine Methode zur Anpassung der Adressierung in beiden Netzwerken aufgezeigt.
5.1 PluriCom: Ein Rechnernetz für leitungsvermittelnde Strukturen
PluriCom ist ein Softwarepaket zur Realisierung von LAN-Basisfunktionen auf einer leitungsvermittelnden Struktur[1]. Es wurde für Dateiübertragung, elektronische Post und den Zugriff auf Datei- und Druckserver in einem ISDN-System, einem V.24-LAN oder über Modem konzipiert. Zur Zeit gibt es Implementierungen für IBM-PC und kompatible Rechner, sowie für Macintosh-Rechner.
Das Programmpaket besitzt die Fähigkeit, selbständig Verbindungen auf- und abzubauen. Als Übertragungsprotokoll wurde eine Kermit-Erweiterung verwendet. Dieses Protokoll ist einfach und daher auf fast allen gängigen Rechnern implementiert. So gibt es Kermit-Implementierungen für PC-DOS-, Macintosh- und UNIX-Rechner, sowie für verschiedene Großrechner. Als Übertragungsgeschwindigkeit wurde 9600 bit/s gewählt, da diese Geschwindigkeit auch von älteren, weniger leistungsfähigen Rechnern gehalten werden kann und vorhandene Endgeräte und Drucker miteinbezogen werden müssen.
Die Kommunikation mit PluriCom findet über die serielle V.24-Schnittstelle statt. Zur Anbindung an das ISDN-Netz sind lediglich V.24-Adapter notwendig, keine Einsteckkarten oder ähnliches. Die Sequenzen zur Verbindungssteuerung und Initialisierungsparameter können an verschiedene Rechnersysteme und Kommunikationsadapter angepaßt werden.
5.1.1 Dateiübertragung über ISPBX mit PluriCom
Das PluriCom-Programm gibt es für PC-DOS- und Macintosh-Computer. PluriCom kann sowohl im Server- als auch im Klienten-Modus betrieben werden. Es ist vorteilhaft, eine Maschine im Netzwerk als Server zu konfigurieren[2]. Die anderen Endgeräte greifen als Klienten auf diesen Server zu. Diese Methode erleichtert die Übertragung von Dateien wesentlich, da keine Absprachen zwischen den Kommunikationspartnern zu treffen sind.
Das Kermit-Filetransfer-Protokoll erlaubt die Kommunikation zwischen einer Vielzahl von Rechnern mit unterschiedlichen Betriebssystemen. Kompatible Erweiterungen des Protokolls unterstützen eine komfortable und einfache Benutzerschnittstelle. Zentrale Eigenschaften dieses Bedienungskomforts sind die kontextabhängige Help-Funktion, die Auswahl aus den grafisch aufgearbeiteten Verzeichnissen sowohl der lokalen Maschine als auch des Servers und die Unterstützung beim Zurechtfinden in den Verzeichnisbäumen (siehe Abb. 5.1.1).
Die Steuerung des Programmablaufs und der Dateiauswahl ist mit einfachen Eingaben über eine Menüauswahl zu bewerkstelligen. Die Menüs lassen sich in einer Parameterdatei konfigurieren. Der Server kommt mit einer Netzwerkschnittstelle aus, da die Klienten zu diesem Port nur während der kurzen Dauer einer Transaktion eine Verbindung unterhalten (fast disconnect operation).
Abb. 5.1.1: Die Auswahl einer Datei und eines Directories
Um eine Datei auf dem Server abzulegen, wird sie im File-Menü ausgewählt. Besteht noch keine Verbindung zum Server, so wird dieser angewählt. Nun wird die Datei übertragen und unmittelbar danach die Verbindung wieder abgebaut. Angemerkt sollte an dieser Stelle noch werden, daß es sich bei PluriCom nicht um ein System handelt, das Remote Disk Access unterstützt, sondern vielmehr um Dateitransfer. Es ist also nicht möglich, Programme von einem Server zu starten.
5.1.2 Electronic Mail
PluriCom enthält eine komfortable Electronic Mail Funktion[3]. Als Briefkästen dienen Paßwort-geschützte Unterverzeichnisse, die auf einem Mail-Server angelegt wurden. Das Versenden und das Abholen von Briefen geschieht mit einem erweiterten Kermit-Filetransfer zwischen Klient und Server.
Abb. 5.1.2: Das Mailbox-Menü und seine Funktionen
Letzterer verteilt die Meldungen in die Empfängerbriefkästen, wobei auch fertige Verteilerverzeichnisse benutzt werden können. Ein kleiner eingebauter Editor erlaubt das Erstellen von kurzen Memos, ohne die Applikation zu verlassen. Durch eine spezielle Funktion „Postkorb beobachten“ ist es möglich, den eigenen Briefkasten periodisch auf eintreffende Nachrichten hin zu überprüfen.
Neben den Datei-Transferfunktionen und dem Elektronic Mail-System enthält der PluriCom-Kermit auch verschiedene lokale Funktionen, wie Löschen, Anzeigen und Drucken einer Datei. Diese sind ebenfalls im Programm integriert (siehe Abb. 5.1.2). Zum Zugriff auf Großrechner und Time-Sharing-Systeme ist der konventionelle Kermit-Betrieb in Form einer Terminalemulation möglich.
5.1.3 Zugang zu abgesetzten Druckern über PDEF10
Der Macintosh erlaubt es, über ein Hilfsprogramm, den sog. Chooser, verschiedene Druckertreiber auszuwählen. Ein modifizierter Druckertreiber sorgt dafür, daß die Druckausgabe direkt über das ISDN-Netz an den Drucker geschickt wird. Treiber sind beim Macintosh-Betriebssystem als Resourcen vorhanden. So ist es möglich, nur Teile von Programmen zu modifizieren oder zu ersetzen. Dem Druckertreiber wird anstelle des Codes, der über AppleTalk druckt, eine Prozedur zur Übertragung über V.24 und PBX eingesetzt. Der Verbindungsauf- bzw. Verbindungsabbau geschieht explizit durch das Öffnen und Schließen des Druckertreibers (transaktionsorientiert).
Der Druckertreiber enthält in der Resource PDEF10 das Printer Access Protokoll (PAP), ein Protokoll der Session-Schicht. Dieses Protokoll ist verbindungsorientiert und besitzt eine schmale Schnittstelle zu den darüberliegenden Schichten (siehe Abb. 5.1.3). Es ist daher leichter auszuwechseln als die darunterliegenden, verbindungslosen Schichten des AppleTalk[4] (ATP, DDP, LAP).
Abb. 5.1.3: Drucken über PBX-PAP
Das PAP umfaßt die Funktionen PAPOpen, PAPRead, PAPWrite, PAPStatus, PAPClose und PAPUnload. Wird die PAPOpen-Prozedur von einer Applikation gerufen, so baut das modifizierte PDEF10 eine Verbindung zum Drucker auf. Die Rufnummer des Druckers kann mit dem Deskaccessory „Wählen“ konfiguriert werden. Über die Prozedur PAPWrite schickt das Modul PDEF0 die Druckbefehle zum Drucker. Die Prozedur PAPRead wird von PDEF0 benutzt, um vom Drucker Informationen über seine Konfiguration anzufordern. Über die Prozedur PAPStatus wird der innere Zustand des Druckers erfragt. Nach dem Drucken wird PAPUnload gerufen und dadurch die Verbindung wieder abgebaut und belegter Speicher freigegeben. Die Struktur des Protokolls erlaubt also eine automatische, transaktionsorientierte Verbindungssteuerung. Schwierigkeiten gab es bei der Implementierung durch eine unsaubere Programmierweise in anderen Moduln des Druckertreibers[5].
Probleme ergaben sich vor allen beim Auswechseln der Transportprozeduren. Da höhere Schichten des Druckertreibers glauben, die Transportschicht zu kennen, verhalten sie sich oft nachlässig (Registerbenutzung, Tricks, undocumented features, unlocked storage). So ist bei allen neuen Versionen des Druckertreibers eine erneute Anpassung notwendig. Positiv zu bemerken ist, daß der gewohnte Druckerdialog voll gewährleistet ist. Der Benutzer hat keine Chance, einen falschen Drucker anzuwählen. Es gibt für den Anwender keinen Bedienungsunterschied zum lokalen Drucken. Einzig die Auswahl des Druckers findet nicht, wie gewohnt, über das Auswahl-, sondern über ein eigenes Wähl-Deskaccessory statt. Die Flußkontrolle zwischen Drucker und Macintosh ist problemlos, da der Drucker auf die serielle Schnittstelle umgestellt werden kann.
5.1.4 Deskaccessories zur Verbindungssteuerung
Um mit vorhandenen Anwendungsprogrammen über die V.24-Schnittstellle weiterhin drucken zu können, muß eine Verbindung aufgebaut werden, während eine Applikation läuft. Das geschieht durch Deskaccessories, die es sowohl bei Macintosh- als auch bei IBM-kompatiblen Rechnern gibt. Macintosh-Deskaccessories sind jedoch besser in das Betriebssystem eingebunden. Ähnlich dem bekannten Sidekick-Programm für PCs oder dem Kontrollfeld am Macintosh können die PluriCom-Deskaccessories aus fast jeder normalen Applikation heraus aufgerufen werden. Mit einem speziellen Tastendruck, dem Hot-Key, oder aus einem besonderen Menü heraus wird das Deskaccessory gerufen. Der Zustand des jeweils laufenden Programmes wird aufbewahrt, so daß die Verarbeitung an genau dem Punkt wieder aufgenommen werden kann, an dem die Unterbrechung erfolgte.
Abb. 5.1.4: Das Deskaccessory Wählen
Das Deskaccessory übernimmt die Verbindungssteuerung zu Geräten, die an das Netzwerk angeschlossen sind. Durch das Deskaccessory „Wählen“ wird bei IBM-kompatiblen Rechnern sichergestellt, daß normale, unveränderte Applikationen ohne besondere Treiber über das Netzwerk drucken können. Der Verbindungsaufbau geschieht kurz bevor die normale Druckfunktion durch das verarbeitende Programm abläuft. Zur Auswahl des Kommunikationspartners dient ein Menü von Namen, Telefonnummern und Icons (vgl. Abb. 5.1.4). Die benötigten Informationen befinden sich in einem Telefonbuch auf der lokalen Platte, das für alle beteiligten Computer gleich sein soll und von einem Server geholt werden kann. Zu den im Telefonbuch gespeicherten Daten gehören neben dem Namen, der Nummer und dem Icon des jeweiligen Teilnehmers auch Informationen über die Art des Endgerätes (Dienstekennung), die Schnittstellenkonfiguration und eventuell Login-Parameter[6]. Das Deskaccessory für den Macintosh ermöglicht zusätzlich die Auswahl eines Laserdruckers im Netz, indem die Nummer des Druckers in die PAPA-Resource eingetragen wird[7].
5.1.5 Beurteilung
Bemerkenswert an PluriCom sind folgende Punkte:
+ PluriCom ist ein System, das sich im Alltag bewährt hat und auch von der Firma Nixdorf vertrieben wird.
- Das PluriCom-Paket bietet nur Ersatz für einzelne wichtige LAN-Funktionen, wie das Drucken oder die Dateiübertragung. PluriCom hat nicht die Flexibilität, die ein LAN aufzuweisen hat. Somit kann es kein vollständiger Ersatz für ein LAN sein.
- Die Verbindungssteuerung in PluriCom benötigt ein Telefonbuch, um die einzelnen Stationen anwählen zu können. Die Adressierung geschieht nicht automatisch. Ein Telefonbuch ist stets zu aktualisieren, was in der Praxis häufig vernachlässigt wird.
5.2 Async AppleTalk im Kiewit-Netzwerk
Async AppleTalk[8] war die erste Anpassung von AppleTalk an ein alternatives Übertragungsmedium und erlaubt eine Verbindung von AppleTalk-Knoten über die asynchrone V.24-Schnittstelle. Die Software bietet eine kostengünstige Anbindung von AppleTalk-Stationen über Modem-Wählverbindungen.
Async AppleTalk sendet Frames von 8-Bit-Daten ohne Paritätsbit und mit einem Stopp-Bit über eine asynchrone Verbindung. Um eine transparente Übertragung zu ermöglichen, werden Sonderzeichen zur Flußkontrolle mit DLE „escaped“ und mit $40 exklusiv „geodert“. Der Anfang und das Ende eines Paketes wird durch ein besonderes Zeichen ($A5) gekennzeichnet. Übertragungsfehler werden durch eine CRC-Prüfsumme entdeckt. Da Vollduplex-Punkt-zu-Punkt-Verbindungen verwendet werden, ist keine Zugriffskontrolle auf das Medium notwendig. Das Async AppleTalk Link Access Protocol (AALAP) verhandelt über spezielle Kontrollpakete die Knotenadresse mit der Gegenseite, um die Eindeutigkeit zu gewährleisten. Für eine geregelte Übertragung ist eine XON/XOFF-Flußkontrolle vorgesehen. Der Macintosh besitzt einen Zilog 8530 als seriellen Baustein, der sowohl asynchron als auch synchron übertragen kann[9]. Prinzipiell ist eine Implementierung des Async AppleTalk auch für andere serielle Bausteine möglich.
5.2.1 Substitution der Verbindungsschicht in Async AppleTalk
AppleTalk ist in Schichten und Protokolle unterteilt[10]. Die Einteilung in Schichten erlaubt die Substitution von gleichartigen Leistungen durch andere Implementierungen. In einem ersten Schritt wurden daher die Protokolle festgelegt, die zu ersetzen waren, um eine Anpassung an ein neues Übertragungsmedium zu erhalten. Das Link Access Protocol (LAP) ist beispielsweise generell für die Übertragung und den Empfang von Paketen von der Hardware zuständig. Die Verbindungsschicht, wie jede andere Schicht auch, besitzt eine klar definierte Schnittstelle, ohne die eine Ersetzung nicht möglich wäre. Verschiedene LAP-Implementierungen können über Hardwareadapter auf unterschiedliche Übertragungsmedien zugreifen. Das ursprüngliche LAP greift auf ein verdrilltes Standard-Kabel zu, das bei Async AppleTalk durch eine Modemleitung oder normale V.24-Verbindung ersetzt wird.
AppleTalk-Protokolle basieren auf der Fähigkeit, Datenpakete an alle anderen Stationen übertragen zu können. Das AppleTalk Link Access Protocol legt die Regeln fest, nach denen auf das AppleTalk-Kabel zugegriffen wird. Genauso, wie Telefongesprächspartner, müssen die LAP-Protokolle darauf achten, daß sich ihre Meldungen nicht überschneiden. AppleTalk benutzt einen dreistufigen CSMA/CA-Algorithmus, um den Zeitverlust durch Kollisionen gering zu halten[11]. Das LAP garantiert nicht, daß ein Paket bei der Gegenseite ankommt. Es wird lediglich gewährleistet, daß, falls ein Paket vom Klienten erhalten wurde, dieses unversehrt und vollständig ist. Ein beschädigtes Paket wird einfach verworfen. Für eine Wiederholung der Übertragung verlorener Pakete ist in AppleTalk die Transportschicht zuständig.
Async AppleTalk Link Access Protocol-Pakete enthalten genau die gleiche Information, die Standard-LAP-Frames enthalten. Der LAP-Rahmen allerdings unterscheidet sich von dem des normalen LAP. AALAP sieht dasselbe Softwareinterface zu den höheren Schichten vor, wie das normale LAP. Die Schichten darüber wissen nicht, daß die Verbindungsschicht ausgetauscht wurde.
5.2.2 Installation
Es gibt zwei Möglichkeiten Async AppleTalk zu installieren. Zum einen kann man den Async AppleTalk-Treiber öffnen, bevor eine Applikation den normalen Treiber öffnet, zum anderen besteht die Möglichkeit den ursprünglichen Treiber im System durch den neuen zu ersetzen. Eine Macintosh-Applikation, die AppleTalk benutzt, kontrolliert, ob der AppleTalk-Treiber schon installiert ist. Öffnet eine Applikation AppleTalk, so wird der neue Treiber geladen. Letztere scheint die einfachere Methode zu sein.
Abb. 5.2.1: Das Deskaccessory zur Installation von Async AppleTalk
Dabei gibt es jedoch einige Schwierigkeiten: Das normale AppleTalk-Netzwerk ist ständig verbunden, wogegen die Async AppleTalk-Wählverbindungen lediglich temporär sind. Um eine Verbindung herzustellen, muß zuerst manuell eine Leitung geschaltet werden. Das Async AppleTalk sieht auch eine Möglichkeit vor, eine unterbrochene Verbindung wieder aufzubauen und bei Beendigung der Sitzung abzubauen. Es muß auch möglich sein, mit derselben Systemdiskette das Standard-AppleTalk und auch das Async AppleTalk zu verwenden. Da Deskaccessories auf dem Macintosh leicht zu implementieren sind und gleichzeitig mit einer Applikation laufen können, wurde zur Installation ein Deskaccessory verwendet. Somit ist es möglich, zum Beispiel aus MacWrite über Async AppleTalk zu drucken, ohne das Programm verlassen oder die Verbindung präventiv aufbauen zu müssen.
Async AppleTalk wird installiert, indem man das Installations-Deskaccessory im Apfelmenü startet. Es erscheint eine Dialogbox mit verschiedenen Auswahlmöglichkeiten und einer Statuszeile. Die Geschwindigkeit ist zwischen 1200 und 19200 Baud wählbar. Der Start-Knopf installiert den Treiber im System und wählt gegebenenfalls über Modem. Der Cancel-Knopf beendet das Deskaccessory ohne Auswirkungen auf die Verbindung. In ein editierbares Textfeld kann eine Rufnummer eingeben werden, welche bei der Installation des Treibers auf Wunsch automatisch angewählt wird. Ist eine Verbindung hergestellt, so wird der Erfolg in einer Statuszeile gemeldet (siehe Abb. 5.2.1). Das Deskaccessory sichert die Konfiguration einer erfolgreichen Verbindung, so daß die Parametereinstellung nicht jedesmal neu vorgenommen werden muß.
5.2.3 Der AALAP-Code im .MPP-Treiber
Jedes AppleTalk-Protokoll stellt eine Ansammlung von Routinen dar. Verschiedene Protokolle des AppleTalk wiederum sind auf dem Macintosh zu Treibern zusammengefaßt. Da Treiber nicht fest an Applikationen gebunden sind, können sie ausgetauscht werden. Der Code des AALAP ist im .MPP-Treiber enthalten und gliedert sich in fünf Teile: Senderoutinen (LAPWrite und der Transmit Interrupt Handler), Empfangsprozedur (der Receive Interrupt Handler), CRC-Algorithmus, eine Pollprozedur und verschiedene Hilfsprozeduren.
Bedient sich nun ein Programm eines AppleTalk-Dienstes, wie etwa den einer ATP-Transaktion, so schickt das AppleTalk Transaktion Protocol (ATP) mehrere Meldungen an das Netz. Für jede Meldung wird eine Prozedur gerufen, um ein Datagramm zu erzeugen. Dieses Datagramm wird von der Prozedur DDPWrite über die Prozedur LAPWrite auf die Leitung geschickt. An dieser Stelle kommt der neue LAP-Code für das Async AppleTalk ins Spiel. Entwickelt wurde dieses neue LAP aus dem M68000-Assembler-Quellcode des ursprünglichen .MPP-Treibers, der die LAP-Prozeduren enthält. Auf diese Weise kam ein Treiber zustande, der für Anwendungsprogramme vollkommen transparent ist. Dennoch ist diese Methode nicht zu empfehlen, da der Code des Treibers sich ständig ändert (neue Versionen), und der gesamte Treiber in Assembler implementiert werden muß.
5.2.4 Senden eines AALAP-Paketes
Immer wenn ein Paket zu senden ist, ruft der Treiber die Prozedur LAPWrite. Hier werden verschiedene Variablen initialisiert und das erste Zeichen des Paketes geschickt. Danach läuft die Übertragung interruptgetrieben ab. Immer, wenn ein Zeichen übertragen ist, wird die CPU unterbrochen und das nächste Zeichen geschickt.
Die Prozedur wird komplizierter durch den Umstand, daß Pakete asynchron geschickt werden können. Das erlaubt es dem Absender im Programm fortzufahren, ohne daß auf die Übertragung gewartet werden muß. Dabei können viele Sekunden vergehen, bis ein Paket übertragen ist. Der Device Manager[12] reiht Operationen in eine Warteschlange ein und führt sie nacheinander aus. Wurde eine Operation abgearbeitet oder ist ein Fehler aufgetreten, so kehrt die Kontrolle sofort zum Device Manager zurück, der daraufhin eine neue Operation anstößt. Kann eine asynchrone Operation, wie etwa die Übertragung eines Paketes, nicht sofort erledigt werden, so kehrt die Kontrolle zu dem Code zurück, der den Device Manager gerufen hat.
Abb. 5.2.2: Die Write Data Structure für ALAP
Die Prozedur LAPWrite benutzt eine besondere Datenstruktur, in der Pakete verpackt sind, die Write Data Structure (WDS)[13]. Diese enthält ein oder mehrere Segmente von Daten, die ein Paket ergeben. Die Struktur besteht aus einer Anzahl von Längen und Zeigerpaaren, die die einzelnen Segmente beschreiben. Die Länge ist jeweils ein Wort und der Zeiger, der auf das erste Zeichen des Segments verweist, ein Doppelwort. In einer WDS können mehrere solche Längen- und Zeigerpaare vorhanden sein, abgeschlossen werden sie immer durch ein Nullwort (siehe Abb. 5.2.2).
In einer globalen Betriebssystemvariablen (ABusVars) an der Adresse $2D8 ist ein Zeiger auf die lokalen Variablen des .MPP-Treibers abgelegt. Diese werden von Async AppleTalk benötigt. Es ist festgelegt, daß dieser Zeiger beim Aufruf von LAPWrite im Register A2 gehalten wird. Damit können .MPP-Variablen mit Offsets zum A2 angesprochen werden.
Vor der Übertragung wird ein Paket auf die maximale Länge von 600 Bytes geprüft. Danach stellt LAPWrite fest, ob zur Zeit bereits ein Paket übertragen wird. Ist das der Fall, so wird geprüft, ob es sich dabei um ein IM- oder UR-Paket[14] handelt, der Zeiger auf die WDS in einer Variablen qWDSptr gespeichert und zurückgekehrt. Andernfalls wird eine Fehlermeldung zurückgeliefert. Kann das Paket übertragen werden, so erneuert LAPWrite den Zeiger auf die PollProc-Prozedur und prüft, ob noch eine Verbindung besteht. Wurde in den letzten 30 Sekunden kein gültiges Paket erhalten, so sendet LAPWrite zum Testen der Verbindung einen IM-Frame. Eine positive Antwort (ein UR-Paket) setzt den Timer zurück und das Paket wird übertragen. Bleibt die Antwort länger als 10 Sekunden aus, so wird der Benutzer aufgefordert, die Verbindung neu aufzubauen.
Abb. 5.2.3: Der AALAP-Rahmen
Besteht eine Verbindung, so ruft LAPWrite die Prozedur SendWDSptr, die den aktuellen WDS sichert und verschiedene Variablen für die Übertragung initialisiert. Schließlich wird das erste Zeichen, der Framing Character ($A5), an den SCC übergeben (siehe Abb. 5.2.3). Der Rest des Paketes wird durch eine Transmit Interrupt-Routine übertragen. Jedesmal, wenn das Transmit-Register des SCC leer geworden ist, wird diese per Interrupt gerufen, um mit TxNextCh ein neues Zeichen zu übertragen. Nach jedem Zeichen wird das Highest Interrupt Under Service-Bit des SCC zurückgesetzt, so daß andere Interrupts zugelassen werden. Durch Aufruf von NextCRC wird dabei die CRC berechnet. Handelt es sich um ein Kontrollzeichen, so wird ein DLE-Zeichen vorweggeschickt und das Zeichen mit $40 exklusiv „geodert“. Ist das letzte Zeichen übertragen, so wird die CRC hinterhergeschickt und das Interrupt Pending-Bit zurückgesetzt. Abgeschlossen wird die Übertragung des Paketes mit einem End Of Frame-Zeichen. Steht keine weitere WDS zur Übertragung an, so wird der Device Manager über die erfolgreiche Übertragung informiert. Andernfalls wird die Übertragung mit einer neuen WDS wieder aufgenommen.
5.2.5 Empfangen eines Frames
Jedesmal, wenn ein Zeichen vom SCC empfangen wurde, wird eine Receive Interrupt-Routine (RIntHnd) gerufen, um das Zeichen von der Schnittstelle entgegenzunehmen. Diese holt ein Zeichen vom SCC ab und prüft, ob noch ein weiteres Zeichen anliegt. Ist das nicht der Fall, so kehrt die Prozedur zum unterbrochenen Programm zurück.
Normalerweise wartet die Prozedur RIntHnd auf den Anfang eines Paketes, indem sie alle ankommenden Zeichen verwirft, bis ein $A5-Zeichen ankommt und die Variable imMsg gesetzt wird. Hat ein Frame begonnen, so wird jedes Zeichen auf „Escaping“ untersucht, gegebenenfalls dekodiert, die CRC errechnet und im Input-Puffer abgelegt. Am Ende eines Paketes wird die CRC auf Gültigkeit überprüft. Ist das Paket unversehrt, so werden die oberen Schichten des AppleTalk gerufen, um es entgegenzunehmen. Pakete mit ungültiger CRC oder ungültiger Länge werden verworfen. Über einen XON/XOFF-Handshake führt die Prozedur auch Flußkontrolle durch. Im Gegensatz zum normalen ALAP liest das AALAP aufgrund der langsameren Übertragungsgeschwindigkeit zuerst den ganzen Frame in einen Puffer ein. Danach läßt das AALAP wieder Interrupts zu und verzweigt erst dann zu den einzelnen Klienten, die das Paket aus dem Puffer lesen. Dadurch muß ein Paket umkopiert werden. Eine Pufferung ist auch deshalb notwendig, da die höheren Schichten mit der Verarbeitung noch nicht fertig sein können, bevor das nächste Paket ankommt.
5.2.6 Hilfsprozeduren
Weitere Komplikationen entstehen dadurch, daß das Betriebssystem des Macintosh die Interrupts für mehr als 100 µs abschalten kann und somit Zeichen verloren gehen können. Vom Betriebssystem ist deshalb eine Prozedur PollProc vorgesehen, mit der Port A gepollt wird, während das Diskettenlaufwerk aktiv ist. Mit Port B ist dies nicht möglich. Es bleibt lediglich die Möglichkeit in PollProc ein Stück Code einzuhängen, das mit XOFF die Gegenseite am weiteren Senden hindert. Fortgesetzt wird die Übertragung durch das XON einer VBL-Task, die dreißigmal pro Sekunde gerufen wird. Wurde eine Sekunde lang kein Zeichen mehr übertragen, so schickt diese VBL-Task versuchsweise das nächste Zeichen auf die Leitung. Weitere Prozeduren setzen die Baudrate am SCC, verhandeln die Node ID und führen Dialoge mit dem Benutzer.
5.2.7 Beurteilung
Async AppleTalk hat einige schwerwiegende Nachteile:
v Die Methode der Einbindung in den AppleTalk Protocol Stack ist heute überholt. Apple Computer hat inzwischen mit dem LAP Manager und dem CDEV Netzwerk eine Möglichkeit geschaffen, eigene Transmit- und Receive-Prozeduren in den .MPP einzuhängen, ohne den Quellcode des .MPP-Treibers zu verändern[15].
v Ein weiterer Nachteil dieser Implementierung ist, daß durch das Einfügen des AALAP-Codes in den ursprünglichen .MPP-Treiber mit jeder neuen Version von AppleTalk eine erneute Anpassung vorgenommen werden muß. Diese Erfahrung wurde auch mit dem PBX-PAP des PluriCom-Paketes gemacht. So ist die letzte Version des Async AppleTalk mit der neuesten Systemversion des Macintosh nicht stabil. Der Quellcode kann, bis auf die Teile, die durch Apple Computer urheberrechtlich geschützt sind, vom Darmouth College bezogen werden.
v Logische Verbindungen in Async AppleTalk können immer nur zwischen zwei Knoten bestehen, da kein flexibler Wechsel der physikalischen Verbindung möglich ist. Der Benutzer muß stets die Rufnummern seiner Kommunikationspartner kennen, da keine automatische Verbindungssteuerung vorhanden ist.
v Zur Zeit gibt es auch noch keine Anbindung an das normale AppleTalk in Form einer Brücke. Sinnvoll erscheint gegenwärtig der Einsatz des Async AppleTalk nur in Verbindung mit dem Kiewit-Netzwerk am Dartmouth College.
5.3 EtherTalk
Ethernet ist der verbreitetste LAN-Standard, für den es eine Anpassung an AppleTalk gibt. Eine Adaption bereitet kaum Schwierigkeiten, da Ethernet ebenso wie AppleTalk auf einer Busstruktur beruht. Dennoch soll hier etwas näher auf Ethernet eingegangen werden, da es eine andere Adreßstruktur wie AppleTalk besitzt und für EtherTalk erstmals der LAP Manager zur Einbindung in den AppleTalk Protocol Stack verwendet wurde[16].
Inzwischen gibt es eine Vielzahl von Produkten, die eine Übertragung von AppleTalk-Paketen über Ethernet ermöglichen. Das kann entweder über eine Brücke oder einen Gateway geschehen oder direkt, indem man die EtherTalk-Software von Apple verwendet (siehe Abb. 5.3.1). Die höhere Geschwindigkeit des Ethernet ist vor allem bei Zugriffen auf Fileserver und größeren Datenbanken von Bedeutung.
Abb. 5.3.1: Das EtherTalk-Icon im Systemfolder
Für den Zugriff auf Ethernet wurde von Apple eine NuBus-Karte für den Macintosh II entwickelt, die sowohl das Standard- als auch das ThinEthernet unterstützt. Mit diesen Karten kann nicht nur AppleTalk über Ethernet betrieben werden, sondern es sind auch andere Protokolle, wie TCP/IP mit den Berkley-Diensten unter dem Macintosh-System und dem Apple-Unix-Derivat A/UX oder NFS unter A/UX, verwendbar. Eine simultane Abwicklung verschiedener Dienste unter verschiedenen Protokollen ist möglich. In einem EtherTalk-Netzwerk können gleichzeitig 254 Geräte aktiv und über 1000 an das gleiche Kabel angeschlossen sein.
5.3.1 Entstehung des Ethernet-LAN-Standards
Anfang der achtziger Jahre entwickelte sich aus einem Forschungsnetz der Labors der Firma Xerox durch Vorlage der Spezifikationen vor das Local Network Standards Commitee des IEEE der Ethernet-Standard.
Es entstand der Standard 802.1, der das LAN-Referenz-Modell, die Schnittstellen zu höheren Schichten, die Adressierung, das Internetworking und das Netz-Management festschreibt[17]. Der Standard 802.2 behandelt den oberen, hardwareunabhängigen Teil der Verbindungsschicht. Die Standards 802.3, 802.4 und 802.5 befassen sich jeweils mit unterschiedlichen Übertragungsmedien und den zugehörigen Zugriffsmethoden (siehe Abb. 5.3.2). Ethernet stützt sich auf den weit verbreiteten Standard 802.3, der als Übertragungsmedium einen Bus auf der Basis eines Koax-Kabels empfiehlt und die zugehörigen Schnittstellen festlegt. Für die Zugriffskontrolle wird ein persistenter CSMA/CD-Algorithmus[18] verwendet. Eine Token-Passing-Bus-Zugriffsmethode wird im Standard 802.4, eine Token-Ring-Zugriffsmethode im Standard 804.5, zusammen mit den Spezifikationen der jeweiligen Bitübertragungsschicht, festgelegt.
Abb. 5.3.2: Die Anordnung der LAN-Standards
Die Bitübertragungsschicht besitzt bei Ethernet die Aufgabe der Übertragung von seriellen Bitströmen zwischen Datensicherungsschicht und physikalischem Übertragungsmedium. Sie übernimmt die Taktgenerierung für Synchronisation und Zeitüberwachung. Weiter sind Einrichtungen zur Kollisionserkennung und zur Überwachung des Mediums auf Verkehr (carrier sense) notwendig. Aufgabe dieser Schicht ist auch die Signalkodierung (Manchestercode), die Erzeugung von Frame-Präambeln und das Testen des Übertragungsweges vom Sender zum Empfänger.
Das Standard-Übertragungsmedium von Ethernet ist ein Koax-Kabel von 50 Ohm. Es hat einen Durchmesser von ca. 10 mm, einen Biegeradius von 25 cm und ist mit gelbem Kunststoff ummantelt. Abgegriffen wird das Koax-Kabel mit einer Medium Attachment Unit (MAU), welche aus dem Terminal Access Point (TAP) und einem Transceiver besteht. Letzterer dient der Übertragung auf dem Teilnehmeranschlußkabel (Transceiver-Kabel), über das der Controller des eigentlichen Terminals erreicht wird. Dieses Kabel zwischen Station und MAU besitzt DB 15-Stecker. Repeater regenerieren bei Segmenten mit einer Länge von über 500 m den Signalverlauf, den Pegel und den Takt.
Die Systemkenngrößen eines 10Base5-Ethernets mit Basisband-Koax-Kabel und 10 Mbit/s Übertragungsleistung sind durch seine Maximalkonfigurationen bestimmt und von der jeweiligen Konfiguration des Netzes unabhängig[19]:
v Ein Koax-Kabel kann maximal 500 m lang sein und muß zur Echokompensierung mit Abschlußwiderständen von 50 Ohm versehen werden.
v Es dürfen höchstens 100 MAUs im Abstand von mindestens 2,5 m angebracht sein.
v Bei einer minimalen Signalgeschwindigkeit von 0,77 c beträgt die Signalverzögerung höchstens 2165 ns. Die Punkt-zu-Punkt-Verbindung eines Remote Repeater soll eine Signallaufzeit von 2165 ns nicht überschreiten. Repeater zählen als MAU und können an beliebiger Stelle angebracht sein. Das Verbindungskabel zwischen zwei Repeatern sollte nicht länger als 1000 m sein.
v Die maximal überbrückbare Entfernung in einem Ethernet beträgt 2500 m, die minimale 2,5 m. Die maximale Distanz erreicht man durch Verkoppelung von 5 Segmenten mit 4 Repeatern, wobei zwei Remote Repeater beteiligt sind, zwei MAUs und zwei AUIs. Von den 5 Segmenten sind maximal 3 Koax-Segmente, die anderen sind Link-Segmente zur Verbindung von Remote Repeatern.
v Ein Transceiver-Kabel ist maximal 50 m lang. Dabei sollte bei einer minimalen Signalgeschwindigkeit von 0,65 c die maximale Signallaufzeit 257 ns nicht überschreiten.
Als billigeres CSMA/CD-10Mbit/s-Netz mit kleineren maximalen Ausdehnungen wurde eine Ethernet-Variante mit der Bezeichnung 10BASE2[20] konzipiert. Dabei wurde lediglich das Medium und die MAU ersetzt. Da die Protokolle und die Übertragungsrate des Ethernet und des Cheapernet übereinstimmen, lassen sich Segmente beider Netzwerke durch einfache Repeater verbinden. Cheapernet-Segmente können nicht mit mehreren normalen Ethernet-Segmenten kombiniert werden. Vielmehr sollen Cheapernet-Segmente peripher an ein normales Backbone-Ethernnet angebunden sein.
5.3.2 Die EtherTalk-Karte
Die EtherTalk-Karte ist das Bindeglied zwischen der EtherTalk-Treibersoftware und dem Ethernet-Kabel. Sie ist für den NuBus des Macintosh II konzipiert und wurde auf der Basis eines LAN-Chipsatzes der Firma National Semiconductor Corporation aufgebaut[21]:
Abb. 5.3.3: Die EtherTalk-Karte für den NuBus
v Ein Netzwerk-Schnittstellen-Controller (NIC) erledigt das Senden, Empfangen und Zwischenspeichern von Ethernet-Datenpaketen. Er erzeugt die Synchronisations- und Vorspanndaten eines Paketes und übernimmt die Berechnung und Überprüfung der CRC.
v Eine serielle Netzwerkschnittstelle (SNI) übernimmt die Kodierung auf der Bitebene, liefert Signale für die Kollisionserkennung (Collision Detection) und enthält eine Diagnoseschaltung.
v Das Coaxial Transceiver Interface (CTI) ist der Anschlußbaustein für des Koax-Kabel (siehe Abb. 5.3.3). Das CTI dient als Sende- und Empfangsbaustein für das dünne Ethernet. Bei Anschluß eines Transceivers für das Standard-Ethernet wird er nicht verwendet.
Die Karte enthält 32 kByte ROM und 16 kByte Video-RAM. Das RAM ist in einen Sende- und Empfangspuffer, und diese wiederum sind in 256 Byte große Speicherblöcke unterteilt. Das ROM enthält eine weltweit eindeutige 48-Bit-Ethernet-Adresse und die NuBus-Software. Über einen Steckverbinder auf der Platine kann zwischen dem dünnen und dem Standard-Ethernet gewählt werden. Der Transceiver für das dünne Ethernet ist auf der Platine vorhanden, für das Standard-Ethernet wird ein externer Transceiver über ein Kabel mit einem DB 15-Stecker angeschlossen.
5.3.3 Die EtherTalk-Software
Die EtherTalk-Software ermöglicht das Betreiben von AppleTalk-Protokollen über die EtherTalk-Karte und das Ethernet-Kabel. Sie besteht aus der Kontrollfeld-Software (dem CDEV Netzwerk und dem ADEV EtherTalk), dem LAP Manager, den INIT-Resourcen, dem AppleTalk Address Resolution Protocol (AARP) und dem Ethernet-Treiber[22]. Letzterer ist für das Senden und Empfangen von Datenpaketen zuständig und bildet die Schnittstelle zur EtherTalk-Karte.
Die Kontrollfeldsoftware ermöglicht durch das CDEV Netzwerk die Auswahl des Übertragungsverfahrens. Das CDEV Netzwerk zeigt bei Auswahl die vorhandenen AppleTalk-Implementierungen an[23]. Durch Anklicken mit der Maus wird die entsprechende Übertragungsart gewählt. Der LAP Manager ist Teil der Sicherungsschicht und hängt den LAPWrite-Code der ausgewählten Implementierung in den LAPWrite Hook des .MPP ein, so daß die Datenpakete über den installierten Code laufen. Es ist auch möglich, einen Macintosh an mehr als nur ein Netzwerk anzuschließen. So kann über eine Karte ein Ethernet und über die serielle Schnittstelle ein LocalTalk angeschlossen sein. Auch mehrere EtherTalk-Karten können betrieben werden, wobei die Slot-Nummern der Karten bei der Auswahl im Kontrollfeld angezeigt werden.
Das AppleTalk Address Resolution Protocol gleicht Unterschiede in der Adressierung in Netzwerken mit unterschiedlichen Protokollen aus. Für EtherTalk übernimmt das AARP die Anpassung zwischen der 48-Bit-Ethernet-Adresse[24] und der 8 Bit langen AppleTalk-Knotenadresse. Die AppleTalk-Adresse, auch Protokolladresse genannt, ist die Node ID und wird dynamisch vereinbart. Die Adressierung in einem Ethernet ist leicht anzupassen, da es sich sowohl bei AppleTalk als auch bei Ethernet um eine Busstruktur handelt, und somit eine Verwaltung von Adressen mit Broadcast-Funktionen leicht realisierbar ist.
5.4 Ethernet-AppleTalk-Brücken
Die direkteste Art der Anbindung von AppleTalk-Stationen an über Ethernet verbundene Unix-Systeme ist eine Ethernet-AppleTalk-Brücke. Eine kommerzielle Version einer solchen Brücke ist FastPath[25]. Sie gestattet eine Vielzahl von Netzkonfigurationen und bietet EtherTalk-Usern die Möglichkeit, auf ein angeschlossenes LocalTalk zuzugreifen. Dadurch wird es zum Beispiel möglich, netzwerkfähige Peripheriegeräte, die AppleTalk unterstützen, in ein Ethernet einzubinden[26].
Mit FastPath kann ein Ethernet als schnelles Backbone-Netzwerk für mehrere LocalTalk-Zonen betrieben werden. Dabei ist es möglich, die einzelnen LocalTalk-Zonen zu einem großen, logischen LocalTalk-Netz zusammenzufassen oder das Netz als Internet mit mehreren eigenständigen Zonen zu konfigurieren. Eine Vernetzung von LocalTalk-Zonen über ein schnelles Backbone-Netz hat auch den Vorteil, daß sie die einzelnen Zonen nicht belastet. Diese Art der Vernetzung wird benutzt, um Abteilungen oder Arbeitsgruppen über mehrere Stockwerke in einem Gebäude zu verbinden. FastPath bietet auch Brückenfunktionen, um von AppleTalk aus den Übergang zu Großrechnern mit anderen Netzwerkprotokollen zu gestatten. Es gibt verschiedene FastPath-Implementierungen für das dünne und das Standard-Ethernet.
5.4.1 Der Seagate-Gateway
Alle bisher bekannten Gateways für Ethernet, auch FastPath, basieren im wesentlichen auf einer Public Domain-Software der Stanford University[27]. Seagate (Stanford Ethernet AppleTalk Gateway) ist eine Brücke, die ein Ethernet mit einem AppleTalk-LAN verbindet und sowohl die AppleTalk Internet-Protokolle als auch das ARPA[28] Internet Protocol unterstützt.
Abb. 5.4.1: Die Protokolle des TCP/IP
Das ARPA Internet Protocol (IP) ist ein universelles Paketprotokoll, vergleichbar mit dem Datagram Delivery Protocol (DDP) des AppleTalk. Das darüberliegende User Datagram Protocol (UDP) stellt einen Datagramm-Service zur Verfügung. Für verbindungsorientierte Endbenutzerdienste liefert das Transmission Control Protocol (TCP) einen kontinuierlichen Bytestrom (vgl. Abb. 5.4.1). Ein Address Resolution Protocol (ARP) wird auf der gleichen Schicht über das Medium betrieben, wie das IP.
Seagate behandelt Routing Table Maintainance Protocol- (RTMP), Name Binding Protocol- und DDP-Pakete auf seinem AppleTalk-Interface. ARPA IP- und ARP-Pakete von EtherTalk werden in DDP-Pakete verpackt (siehe Abb. 5.4.3). Seagate übernimmt die Weglenkung von DDP-Paketen zwischen Segmenten, legt die Identität von Segmenten über das RTMP fest und verteilt NBP-Requests. Mit dem passenden Hilfsprogramm ausgestattet, können Prozesse auf Unix-Hosts AppleTalk-Dienste nutzen. So kann z.B. ein Unix-System Postscript-Dateien an einen Laserdrucker im AppleTalk-Netzwerk schicken.
Auf seinem Ethernet-Interface behandelt Seagate normale ARPA IP- und ARP-Pakete. Die RTMP-, DDP- und NBP-Pakete von AppleTalk werden in passend adressierte UDP-Pakete verpackt (siehe Abb. 5.4.4). Solche UDP-Pakete werden von Programmen auf Ethernet-Hosts, die mit der normalen IP/UDP-Software betrieben werden, empfangen und gesendet. Unter Apple-Unix (AU/X) laufen auf Macintosh-Rechnern Standard-Internet-Unix-Anwendungen. Somit lassen sich für Macintosh-Rechner Unix-Server für Datei- und Druckerzugriff oder andere Dienste einrichten.
5.4.2 Seagate-Hardware und -Software
Die Seagate-Hardware besteht aus einem Multibussystem aus mit Karten: Einer CPU, einer Ethernet-Karte und einer AppleTalk-Interfacekarte. Die CPU und die Ethernet-Karte sind käuflich zu erwerben, die AppleTalk-Karte wurde nach der Stanford-Empfehlung gebaut. Die CPU-Karte ist um einen M68000 aufgebaut, besitzt 256 kByte dynamisches RAM mit Softwarerefresh, einen Monitor im PROM, zwei serielle Ports und einen Quarz zur Taktgenerierung. Das Ethernet-Board benutzt einen 82586 Ethernet-Chip und kommuniziert über ein 8 kByte Video-RAM.
Der Großteil der AppleTalk-Protokolle ist durch Software realisiert. Die AppleTalk-Karte benutzt eine abgemagerte Version dieser Software. Um die Änderungen an der Software gering zu halten, wurde die gleiche Hardware wie beim Macintosh verwendet. Der wichtigste Bestandteil der Karte ist der Zilog Z8530 Serial Communications Controller. Die restlichen Bauteile dienen der Verbindung des SCC über den Multibus mit der CPU.
Liegt ein Paket mit der passenden Adresse an, so unterbricht der SCC die CPU. Zusätzlich pollt die CPU den SCC alle 35 µs, um Zeichen zu lesen oder zu schreiben. SCC-Interrupts müssen sofort behandelt werden, um zu verhindern, daß der Receive-FIFO-Puffer des SCC überläuft. Aus diesem Grund kann die CPU nur eine AppleTalk-Verbindung bedienen.
Die Gateway-Software wurde nach dem original AppleTalk Link Access-Code in C implementiert und mit etwas Assembler-Glue versehen. Sie läuft als einzelner Prozeß mit interruptgetriebenen Gerätetreibern und ohne Betriebssystem. Eine Interruptroutine reiht ankommende Pakete in eine Warteschlange ein. Der Prozeß arbeitet die Schlange ab und behandelt die Pakete. Verschiedene Hintergrund-Tasks werden abgearbeitet, sowie Zeit dafür ist.
5.4.3 Brückenadressierung
Bevor eine Brücke ein Paket übertragen kann, müssen ihr die Adressen der Klienten sowohl im AppleTalk- als auch im ARPA-Bereich bekannt sein. Das kann über eine große Adreßtabelle geschehen. Um einen Algorithmus mit einer kleineren Tabelle verwenden zu können, nutzt der Seagate die Ähnlichkeit der Adreßstruktur in beiden Netzen:
Die AppleTalk-Knotenadresse besteht aus einer 16-Bit-Netzwerknummer und einer 8-Bit-Node ID. Eine ARPA-Knotenadresse ist 32 Bit lang, wobei die ersten 2 Bit anzeigen, ob es sich um eine Netzwerk- oder um eine Knotenadresse handelt. Ethernet-Adressen sind 48 Bit lang und werden vom Hersteller festgelegt. Die Abbildung von ARPA- auf eine Ethernet-Adresse wird von ARP übernommen. Um festzustellen, ob ein Knoten mit einer bestimmten ARPA-Adresse vorhanden ist, wird ein ARP-Request-Paket auf die Leitung geschickt. Der Knoten mit der gesuchten Adresse sendet ein Antwortpaket, das die Ethernet-Adresse enthält. Zusätzlich zu Ethernet unterstützt Seagate das ARP auf einem AppleTalk-Segment und bestimmt die zur ARPA-Adresse korrespondierende AppleTalk-Adresse.
Die Beziehung zwischen der AppleTalk- und der ARPA-Adresse eines bestimmten Host hängt von den Einträgen in der Mapping Table des Seagate ab. Diese Tabelle kann sowohl Einträge für Knoten als auch für Netzwerke enthalten. Ein Host-Eintrag bildet seine AppleTalk-Netzwerk- und -Knotenadresse auf eine beliebige ARPA-Adresse ab. Ein Netzwerkeintrag bildet ein AppleTalk- auf ein ARPA-Netzwerk ab, indem die AppleTalk-Node ID zu den letzten 8 Bit der ARPA-Adresse wird.
|
|
Mac |
Seagate AppleTalk port |
Seagate
Ethernet port |
VAX |
|
ARPA |
64.10.0.42 |
64.10.0.198 |
64.5.0.64 |
64.5.0.1 |
|
AppleTalk |
10/42 |
10/198 |
5/64 |
5/1 |
Abb. 5.4.2: Das Address Mapping zwischen AppleTalk- und ARPA-Segmenten
Wird beispielsweise eine ARPA-Netzwerknummer 64, eine Ethernet-Unternetznummer 5 und eine AppleTalk-Unternetznummer 10 festgelegt, dann erhalten Ethernet-Hosts die Adressen 64.5.0.nn im ARPA- und 5/nn im AppleTalk-Bereich. AppleTalk-Hosts besitzen die Adressen 64.10.0.nn und 10/nn. Dabei handelt es sich dann nicht um einen Teil des ARPA-Netzes und es bedarf keines Eintrags in der Mapping Table. Etwas anders verläuft das Address Mapping bei der Übertragung von ARPA-IP-Paketen nach AppleTalk. Die Hostadresse im Unternetz wird dann durch das ARP bestimmt.
AppleTalk-Sockets werden durch 8-Bit-Zahlen bezeichnet, wobei die ersten 128 Werte für statische und der Bereich von 128 bis 254 für dynamisch vereinbarte Sockets stehen. Die meisten Klienten des NPB benutzen dynamische Sockets. ARPA Internet Sockets werden durch 16-Bit-Zahlen festgelegt, wobei jedes Protokoll eine eindeutige Socket-Adresse besitzt. Nach Vereinbarung werden die ersten 1000 Adressen durch privilegierte Dienste genutzt und der Rest steht dynamisch zur Verfügung. Werden AppleTalk-Pakete in UDP-Pakete verpackt, so werden die ersten 128 Socket-Adressen auf den privilegierten und die restlichen 128 auf den unprivilegierten Bereich abgebildet. In DDP-Pakete verpackte ARPA-Pakete werden immer an den AppleTalk-Socket 72 geleitet.
5.4.4 Paketübertragung durch den Gateway
Kommt in der Brücke ein AppleTalk-Paket an, so wird der Pakettyp untersucht, denn nur auf kurze oder lange DDP-Pakete wird geantwortet. NBP-, eingebettete IP-, und ARP-Pakete werden herausgefiltert und einer gesonderten Behandlung unterzogen. Bei NBP-Paketen werden Requests an den Gateway in LookUp-Requests umgewandelt und sowohl auf dem AppleTalk- als auch auf dem Ethernet-Segment abgesetzt. LookUp-Requests des Name Bindings werden ignoriert. LookUp-Replies werden ihrer Zieladresse entsprechend weitergeleitet. Verpackte IP-Pakete werden ausgepackt und an den IP-Router weitergegeben (siehe Abb. 5.4.3). Dieser leitet Ethernet-Pakete zu einem lokalen Host oder zu einem Gateway zum abgesetzten Host, oder er verwirft sie einfach. Verpackte ARP-Pakete werden ebenso ausgepackt und analysiert. Handelt es sich um eine Anfrage für eine Unternetzadresse, die dem Ethernet-Segment entspricht, so sendet der Seagate eine Antwort mit seiner eigenen AppleTalk-Adresse und signalisiert somit, daß er bereit ist, IP-Pakete mit dieser Adresse weiterzuleiten.
Abb. 5.4.3: Der Austausch von ARPA-Paketen über Seagate
Auf der Ethernet-Seite erkennt der Gateway ARP- und IP-Pakete. Er antwortet auf ARP-Anfragen sowohl an seine Adresse als auch an Adressen im AppleTalk-Segment. Auf IP-Datagramme antwortet er, wenn sie an das AppleTalk-Segment adressiert sind. Handelt es sich um ein UDP-Paket für Socket 72, so wird angenommen, daß es sich um ein verpacktes AppleTalk-Paket handelt. Der IP/UDP-Header wird entfernt und der Rest als DDP-Datagramm weitergeleitet (siehe Abb. 5.4.4). Andere Pakete werden in DDP-Pakete gepackt und an den Host adressiert, dessen Internet-Adresse durch das ARP bestimmt wurde. Alle übrigen Pakete sind an Knoten außerhalb des Netzbereiches gerichtet. Sie werden deshalb als ARPA-UDP-Datagramm verpackt und mit einer ARPA-Bereichsadresse versehen weitergeleitet. Sockets werden behandelt, wie oben beschrieben. Der LAP- und der DDP-Kopf werden mitverpackt, so daß der Empfänger das Paket auspacken kann, ohne die UDP- in AppleTalk-Adressen umsetzen zu müssen.
5.4.5 Einsatz des Seagate-Gateways
Zur Zeit gibt es drei Arten von Anwendungen für Seagate: Terminal-Emulationen für Unix-Hosts, das External File System (EFS) und Druckerspooler, die das Drucken mit LaserWritern im AppleTalk-Netz von Unix-Systemen aus ermöglichen.
Terminal-Emulationen benutzen ein ARPA-Protokoll, das Filesystem und der Druckerspooler verwenden AppleTalk-Protokolle und verlangen so Serverprozesse auf Unix-Maschinen, die AppleTalk beherrschen. An der Universität von Nothingham wurden AppleTalk-Protokolle für solche Server in der Programmiersprache C entwickelt. Darüber hinaus wurde an der Columbia University eine Bibliothek von Routinen erstellt, die den Bau einer Serverapplikation wesentlich erleichtert (CAP). Für das IP-Protokoll gibt es einige Implementierungen für den Macintosh, die größtenteils auf der MIT IBM-PC-Version in C basieren. Sie beinhalten eine Telnet- und eine Trivial File Transfer Protocol (TFTP)-Implementierung (siehe Abb. 5.4.3). Die Telnet-Applikation emuliert ein DEC VT-100-Terminal an einem Unix-Host. Während einer Sitzung kann mit dem TFTP-Protokoll ein Filetransfer im Hintergrund ablaufen.
EFS erlaubt es, mehrere Unix-Directories als Macintosh-Volumes zu „mounten“. Ein Filetransfer verläuft, wie beim Kopieren einer Datei im Filesystem, mit der Maus. Applikationen auf dem Server lassen sich, wie gewohnt, starten. Installiert wird das EFS über ein kleines Hilfsprogramm, das die Netzwerktreiber lädt. Ein Mount-Programm in Form eines Deskaccessories erlaubt es, jederzeit Verbindungen zu einem bekannten Host herzustellen und Directories als Volumes anzusprechen. Nach Aufbau der Verbindung erscheint für das Directory ein Diskettensymbol auf dem Desktop.
Abb. 5.4.4: Die Weiterleitung von AppleTalk-Paketen über Seagate
Macintosh-Dateien können in Unix nicht als eine Datei abgespeichert werden und müssen in drei Teilen abgelegt werden. Die Datenfork wird unter dem ursprünglichen Namen und mit der Endung ‘.DF’ abgespeichert. Entsprechend wird mit der Info- und der Resource-Fork verfahren. Dabei wird in jedem Directory ein Desktopfile erzeugt, das den Zustand des Desktops beinhaltet. Zur Zeit werden die Volumes noch wie MFS- (Macintosh File System) und nicht wie HFS-Volumes (Hierarchical File System) behandelt. Abbildung 5.4.4 zeigt die Architektur des EFS. Auf einem Host läuft dabei ein Serverprozeß, der sich bei jeder neuen Verbindung aufteilt. Wird ein Macintosh abgeschaltet, so stirbt der zugehörige Tochterprozeß im Host. Ein Name Binding-Prozeß auf einem Unix-Host erlaubt die Suche nach benannten Einträgen auf dem Netz.
Ein weiterer wichtiger Punkt ist die Anbindung eines AppleTalk-LaserWriters an ein Unix-Netz. Dazu muß ein neues Printer Access Protocol (PAP) entwickelt werden. Auch hierzu ist in der CAP-Bibliothek ein PAP und ein Druckerspooler vorhanden. Über diesen Spooler kann sowohl ein Macintosh als auch ein Unix-System Druckaufträge an einen Spooler auf einem Unix-Host schicken.
5.4.6 Probleme mit dem Gateway
Bei der Implementierung dieses Gateways waren zahlreiche Probleme zu überwinden. Eines davon war der Verlust jedes hundertsten zu empfangenden Paketes, da der SCC keinen DMA-Zugriff besitzt und sich dadurch Timingprobleme ergeben. Das liegt daran, daß der M68000 keinen Interrupt behandeln kann, während der Refresh des dynamischen RAM der Karte durchgeführt wird. Die verlorenen Pakete verursachen nach dem Ablauf von oft langen Timeouts Paketwiederholungen, wodurch es zu einer drastischen Verringerung des Durchsatzes kommt[29]. Gegenwärtig wurde das Problem durch Aufteilen des Refreshzyklus gelöst.
5.4.7 Beurteilung von EtherTalk und Seagate
EtherTalk ist eine gelungene Portierung von AppleTalk auf ein neues Übertragungsmedium. Erleichtert wird diese Portierung allerdings dadurch, daß die Ethernet-Hardware prinzipiell dieselben Anforderungen erfüllt, wie die AppleTalk-Hardware. EtherTalk war die erste professionelle Portierung von AppleTalk auf ein alternatives Medium. Eine Anpassung von AppleTalk an Ethernet völlig anderer Art ermöglicht der Seagate. Dadurch wird es erstmals möglich, AppleTalk- und Ethernet-Segmente zu verbinden. Alle bisher erhältlichen kommerziellen Gateways sind Weiterentwicklungen dieser Implementierung. An ihr wurden erstmals die Probleme, die mit einer Anbindung verbunden sind, diskutiert. Beide Konzepte finden Eingang in die Anpassung von AppleTalk an eine ISDN-Struktur.
5.5 Weitere Anpassungen
Neben den eben beschrieben Anpassungen von AppleTalk an eine andere Hardware- und/oder Systemumgebung, existiert eine Reihe weiterer Adaptionen an fast alle gängigen Systeme und Netzwerke. Dabei muß zwischen einem reinen Tausch des Übertragungsmediums ohne Softwareanpassung, einem Austausch des Übertragungsmediums, der einer Softwareanpassung bedarf, und einer Anbindung über eine Brücke oder einen Gateway unterscheiden werden.
Eine der verbreitetsten Anpassungen von AppleTalk an Lichtwellenleiter ist das Fiber Optic LAN System[30]. Eine Verbindung von AppleTalk-Stationen über normale, ungenutzte Telefonverkabelungen bietet PhoneNet[31]. TokenTalk unterstützt das Betreiben von AppleTalk auf einem Token-Ring. Das Verbinden von AppleTalk-Knoten über Modemverbindungen und Nullmodems ermöglicht Dial-In[32]. Zur Erhöhung der Übertragungsleistung von AppleTalk wurde das Hard- und Software-Konzept DaynaTalk[33] erarbeitet, das Übertragungsraten bis 850 kBaud erlaubt. Ein Anbindung an DECNet bietet AppleTalk for VMS/VAX. Für eine detailierte Beschreibung der Eigenschaften dieser Adaptionen wird auf die Literatur verwiesen[34].
Auch wenn sich die Rahmenbedingungen erheblich unterscheiden, so haben die vorgestellten Konzepte ähnliche Schwierigkeiten zu überwinden, wie ein Link Access Protocol für ISDN und eine ISDN-AppleTalk-Brücke.