6. Adaption durch Protokollsubstitution
Nachdem im vorangegangenen Kapitel einige exemplarische Konzepte zu Adaption von AppleTalk vorgestellt wurde und auch die Funktionsweise des AppleTalk Protocol Stacks bekannt ist, muß nun für die Anpassung an ISDN eine geeigente Schnittstelle und eine adäquate Methode gefunden werden, ein Protokoll im AppleTalk Protocol Stack zu ersetzen. Außerdem ist zu klären, wie und in welcher Form AppleTalk-Pakete über ISDN-Verbindungen übertragen werden können.
6.1 Wahl der Protokollschnittstelle
AppleTalk ist nach dem OSI-Schichtenmodell gegliedert. Daher ist es möglich verschiedene Protokolle des AppleTalk gegen neue Versionen und Implementierungen auszutauschen. Dabei sind jedoch folgende Punkte zu berücksichtigen:
v Mehrere höhere Protokolle greifen direkt auf untere Schichten im Protocol Stack zu, ohne die Dienste der dazwischenliegenden Ebenen zu nutzen. Der Austausch einer Schicht, die unter Umständen übergangen werden kann, genügt daher nicht. Es muß eine gemeinsame Basis für eine Substitution gefunden werden.
v Der Zugriff auf die
substituierte Schicht muß für die höheren Schichten im Protocol Stack
transparent bleiben. Alle Funktionen müssen voll gewährleistet sein.
v Hinderlich ist weiterhin, daß verschiedene Protokolle zu Treibern zusammengefaßt sind und damit mit einem Protokoll der gesamte Treiber ersetzt werden muß.
v Zu berücksichtigen ist auch der Aufwand, der betrieben werden muß, um eine Schicht zu ersetzen. Je mehr Wechselwirkungen zwischen einem Protokoll und seinen Klienten stattfinden, desto aufwendiger wird eine Substitution. Daher muß versucht werden eine schmale Schnittstelle zu finden.
Ziel einer Protokollsubstitution muß es vor allem sein, die volle Funktionsfähigkeit eines Netzwerkes zu erhalten und den entstehenden Implenentierungsaufwand zu minimieren. Daher muß die Wahl der Schnittstelle für den Austauch eines Protokolls sehr sorgfältig geschehen. Mit dieser Aufgabe beschäftigen sich die folgenden Abschnitte.
6.1.1 Substitution der Transportschicht
Die oberste datenübertragende Schicht ist die Transportschicht. Die Ersetzung des Transportprotokolls hat eine Veränderung der gesamten Paketübertragung des AppleTalk zur Folge (vgl. Abb. 6.1.1).
Ein Austausch der Transportschicht hat die Vorteile:
+ Auf den ersten Blick würde sich eine transaktionsorientierte Verbindungssteuerung leichter implementieren lassen[1].
+ Die Protokolle der Transportschicht des AppleTalk, insbesondere das Transportprotokoll, liegen als eigenständige Treiber vor und können daher ersetzt werden.
Schwerwiegender als die Vorteile sind jedoch die Nachteile beim Austausch der Transportschicht:
- Auf der Transportschicht des AppleTalk befindet sich nicht nur das ATP, sondern eine Reihe weiterer Protokolle, die ebenso ersetzt werden müßten.
- Höhere Protokolle und Klienten des AppleTalk greifen nicht nur über die Transportschicht auf das Netzwerk zu, sondern nutzen zum Teil direkt die Protokolle der Schichten 2–3 (z.B. das ADSP, vgl. hierzu auch Abbildung 4.2.1).
- Durch mehrere konkurrente Transaktionen ergeben sich Probleme mit einer transaktionsorientierten Verbindungssteuerung[2].
- Um zwischen dem Standard-AppleTalk und der ISDN-Implementierung wechseln zu können, muß ein eigenes Installationsprogramm geschrieben werden, das die Treiber auswechselt.
- Als weiterer Nachteil einer Substitution dieser Schicht muß der hohe Implementierungsaufwand gewertet werden, der durch die vielfältigen Wechselwirkungen mit den Klienten der Transportschicht und durch die Fähigkeit des ATP, mehrere Transaktionen verwalten zu können, entsteht.
Abb. 6.1.1: Substitution der Transportschicht
Ein Austausch der Transportschicht ist also nicht ratsam. Die Netzwerkschicht des AppleTalk hingegen würde mit dem DDP über eine gemeinsame Basis verfügen, auf die alle Protokolle zugreifen[3]. Das Problem hierbei ist jedoch das Fehlen einer klaren Schnittstelle. Das DDP ist mit den NBP- und den LAP-Prozeduren so eng verflochten, daß es zusammen mit diesen in einem gemeinsamen Treiber untergebracht ist und ein Austausch nur schwer möglich erscheint.
6.1.2 Substitution der Verbindungsschicht
Die Verbindungschicht ist die unterste, hardwarenahe Software-Schicht. Neben dem Austausch der Transportschicht bietet sich aus folgenden Gründen eine Ersetzung dieser Schicht an:
+ Auf der Verbindungsschicht des AppleTalk befindet sich nur ein einziges Protokoll, das AppleTalk Link Access Protocol (ALAP). Neben dem DDP bietet auch das LAP eine gemeinsame Basis, der sich alle Protokolle und Klienten bedienen.
+ Anders als für das DDP gibt es für das Link Access Protocol eine Schnittstelle, die (mehr oder weniger klar) dokumentiert ist. Diese Schnittstelle bildet der LAP Manager, der den Austausch des LAP erleichtern soll. Gleichzeitig können so auch weitere Link Access-Protokolle, wie EtherTalk und TokenTalk, unterstützt werden.
+ Die Verbindungsschicht ist die unterste, hardwareabhängige Schicht. Daher stellt das Link Access Protocol das Minimum der dessen dar, was bei der Änderung des Übertragungsmediums ersetzt werden muß (Abb. 6.1.2).
+ Eine objektorientierte Verbindungsteuerung ist auf der Verbindungsschicht gut zu implementieren. Als Objekte gelten LAP-Pakete.
Abb. 6.1.2: Substitution der Verbindungsschicht in AppleTalk
Die angeführten Vorteile legen den Austausch des LAP-Protokolls nahe. Im folgenden Abschnitt werden daher Methoden vorgestellt, wie das LAP im AppleTalk Protocol Stack ersetzt werden kann.
6.2 Ein Link Access Protocol für ISDN (ISDNLAP)
Das AppleTalk Link Access Protocol ist Teil des .MPP-Treibers. Daher ist noch zu klären, wie die Standard-LAP-Prozeduren durch eigene Prozeduren für das Lesen und Schreiben von Paketen und zur dynamischen Node-Adressierung in diesem Treiber ersetzt werden können. Zwei Methoden, die in Kapitel 5 anhand von Beispielen bereits vorgestellt wurden und hier kurz diskutiert werden sollen, bieten sich an:
6.2.1 Ersetzen des LAP-Codes im .MPP-Treiber
Die erste Methode ist als »Poor Man's Approach« anzusehen. Im Quellcode des .MPP-Treibers werden die LAP-Prozeduren durch eigene Routinen ersetzt[4]. Diese Methode hat jedoch folgende, gravierende Nachteile:
v Der Quellcode unterliegt dem Copyright der Firma Apple und muß von dieser zur Verfügung gestellt werden. Ein großes Mysterium sind dabei die lokalen .MPP-Variablen, auf die die globale Betriebssystemvariable ABusVars verweist und deren Struktur nicht dokumentiert ist.
v Mit jeder neue Version des .MPP-Treibers muß erneut eine Anpassung der LAP-Prozeduren vorgenommen werden[5].
v Der Code des .MPP-Treibers wurde vollständig in Assembler erstellt und ist ziemlich undurchsichtig und verschränkt. Eine Programmierung in Assembler erschwert die Implementierung und mindert die Wartbarkeit des Codes.
v Zur Installation des modifizierten Treibers ist ein Installationsprogramm notwendig[6].
6.2.2 Substitution des LAP mit dem LAP Manager
Eine neuere Möglichkeit das LAP im AppleTalk Protocol Stack zu ersetzen, bietet der LAP Manager, wie er in Abschnitt 6.2.3 vorgestellt wird. Der LAP Manager ist ein Interface zwischen dem LAP und den übergeordneten Schichten (vgl. Abb. 6.2.1). Eine Substitution des LAP durch den LAP Manager hat folgende Vor- und Nachteile:
+ Der LAP Manager bietet eine schmale Schnittstelle zum Austausch des LAP.
+ Die Installation eines alternativen Link Access Protocols wird für den Benutzer sehr einfach und erlaubt es zwischen mehreren AppleTalk-Übertragungsmedien zu wählen.
+ Nicht zuletzt wird diese Methode von Apple unterstützt. Somit ist anzunehmen, daß ein Kompatibilität mit künftigen AppleTalk-Versionen gewährleistet ist.
+ Zur Substitution des LAP ist keine Änderung des .MPP-Treibercodes notwendig.
- Die Dokumentation ist in vielen Fällen unzureichend und unvollständig, so daß sich viele offene Fragen ergeben, die oft nur nach dem „Try and Find“-Prinzip gelöst werden können.
Abb. 6.2.1: Wirkungsweise des LAP Managers
Die Vorteile des LAP Managers überwiegen die bekannten Nachteile. Zur Einbindung eines Link Access Protocols für ISDN in den AppleTalk Protocol Stack wurde daher der LAP Manager verwendet. Eine detailierte Beschreibung des Einsatzes des LAP Managers wird im nächsten Abschnitt und in Anhang B gegeben.
6.2.3 Der LAP Manager
Das Softwarepaket des LAP Managers wurde entwickelt, um die Kommunikationsfähigkeit des Macintosh zu erweitern. Mit seiner Hilfe wird es möglich, AppleTalk über verschiedene alternative Übertragungsmedien zu betreiben. Erstmalig wurde der LAP Manager zur Installation von EtherTalk eingesetzt. Er eignet sich aber auch für die Entwicklung neuer, alternativer AppleTalk-Implementierungen. Zur Zeit wird nur ein aktives LAP unterstützt. Spätere Versionen sollen mehrere aktive LAPs, wie sie in einer Brücke benötigt werden, handhaben können.
6.2.3.1 Die Komponenten des LAP Managers und ihre Aufgaben
Der LAP Manager besteht aus mehreren Komponenten mit unterschiedlichen Aufgaben:
v Dem eigentlichen LAP Manager: Er befindet sich zwischen dem AppleTalk Protocol Stack und den LAPs aller AppleTalk-Verbindungen und regelt die Wechselwirkungen zwischen dem Protocol Stack und dem jeweils aktiven LAP. Somit wird sichergestellt, daß sich verschiedene LAP-Implementierungen nicht gegenseitig stören oder auf die lokalen Informationen der AppleTalk-Treiber zugreifen können. Der LAP Manager wird beim Systemstart in den System Heap geladen, noch bevor das eigentliche AppleTalk geöffnet wird. Er kontrolliert den LAPWrite Hook, der in der globalen Betriebssystemvariablen ATalkHk2 festgelegt wird. Der .MPP-Treiber benutzt diesen LAPWrite Hook, um Pakete an das ausgewählte LAP zu übergeben. Beim Empfangen von Paketen übernimmt der LAP Manager das Verteilen der Pakete an die über den LAP-Typ zugeordneten Protocol Handler.
v Dem CDEV Netzwerk: Ein Control Panel Device File (CDEV) regelt über das Kontrollfeld die Einstellungen, die der Benutzer am Rechner vornimmt. Das CDEV Netzwerk befindet sich, wie alle übrigen CDEVs, im System Folder. Es erlaubt dem Benutzer über das Kontrollfeld eine AppleTalk-Verbindung zu wählen. Das CDEV enthält verschiedene Resourcen, um vorhandene AppleTalk-Verbindungen (ADEV) anzuzeigen und die Auswahlinformation dem System bekanntzumachen. Beim Öffnen durchsucht das Kontrollfeld den System Folder nach CDEV-Files und zeigt sie am linken Rand des Kontrollfeldfensters an (vgl. Abb. B.5.1). Wird unter diesen CDEVs das CDEV Netzwerk ausgewählt, so durchsucht es den System Folder nach ADEV-Files und zeigt die zugehörigen Icons im Kontrollfeld an. Dabei greift das CDEV kurz auf jedes ADEV zu, um Informationen über die unterstützten Verbindungen zu erhalten. Durch Klicken mit der Maus kann über das Icon die gewünschte AppleTalk-Verbindung ausgewählt werden. Das Icon des ausgewählten Netzwerkes wird invertiert dargestellt, wie in Abbildung B.5.1 deutlich zu erkennen ist. Über das CDEV wird ein alternatives LAP auch wieder deinstalliert.
v Dem AppleTalk Device File (ADEV): Ein ADEV-File ist ähnlich aufgebaut wie ein CDEV-File. Es enthält mehrere verschiedene Resourcen, die für das Anzeigen im Kontrollfeld, die Installation und die Übertragung von AppleTalk-Paketen benötigt werden. In einer 'ICN#'-Resource befindet sich das im Kontrollfeld angezeigte Icon. Die 'STR '-Resource enthält den Namen des ADEV im Kontrollfeld. Über die 'BNDL'- und 'FREF'-Resource wird dem ADEV ein Icon im Finder zugeordnet. Eine 'adev'-Resource enthält die „stand alone“-Prozeduren, die beim Anzeigen der ADEVs im Kontrollfeld in den System Heap geladen und vom CDEV Netzwerk gerufen werden. Der eigentliche Code der alternativen LAP-Implementierung befindet sich in der 'atlk'-Coderesource. Zusätzlich kann das ADEV-File noch verschiedene implementierungsspezifische Resourcen enthalten.
v Dem LAP Manager INIT: Wird ein alternatives LAP über das CDEV Netzwerk ausgewählt, so registriert dieses die zugehörige ID im Parameter RAM. Dadurch bleibt die Information, welche AppleTalk-Verbindung aktiv ist, auch nach dem Abschalten des Gerätes erhalten. Beim Systemstart installiert die LAP Manager INIT-Resource im System File die ausgewählte 'atlk'-Resource ähnlich wie das CDEV Netzwerk. Das INIT holt sich den Wert der zuletzt ausgewählten AppleTalk-Verbindung aus dem Parameter RAM, lädt den zugehörigen Code in der 'atlk'-Resource in den System Heap, ruft diesen zur Initialisierung und löst den 'atlk'-Code vom Resource File[7] (detached). Zudem ist das LAP Manager INIT für das Laden und die Initialisierung des eigentlichen LAP Managers zuständig.
v Ein AppleTalk Address Resolution Protocol (AARP) dient der Abbildung von AppleTalk-Adressen auf die Adreßstrukturen verschiedener Protocol Stacks in einem Knoten[8]. Dieses Protokoll gibt es bis jetzt nur in einer Implementierung für EtherTalk. Im wesentlichen besteht es aus einer Anzahl von Regeln im Umgang mit einer Adreßtabelle für AppleTalk.
6.2.3.2 Wechselwirkungen zwischen den Komponenten
Zwischen den einzelnen Teilen der LAP Manager-Software werden bei verschieden Gelegenheiten Informationen ausgetauscht. Dialoge finden zwischen dem CDEV Netzwerk und dem 'adev'-Code bzw. dem 'atlk'-Code statt. Wechselwirkungen gibt es auch zwischen dem CDEV Netzwerk, dem LAP Manager und dem 'atlk'-Code.
Abb. 6.2.2: Wechselwirkung zwischen CDEV Netzwerk und 'adev'-Resourcen
Wählt der Benutzer das CDEV Netzwerk im Kontrollfeld aus, so fordert dieses von jedem ADEV-File im System Folder Informationen an, indem es mehrere GetADEV-Calls an den zugehörigen 'adev'-Code richtet (siehe Abb. 6.2.2). Der erste Aufruf enthält jeweils den Parameter 0.
Der 'adev'-Code antwortet auf jeden GetADEV-Call mit Information über das vom ADEV unterstützte LAP. Diese Information enthält einen Status, der den Zustand der Verbindung anzeigt, eine Variable und einen Zeiger auf den String, der unter dem Icon im Kontrollfeld erscheinen soll. Anhand der Statusinformation kann das CDEV erkennen, ob ein weiterer GetADEV-Call an das ADEV gerichtet werden muß. Ist das erforderlich, so enthält der GetADEV-Call als Parameter den Wert der Variablen, der vom letzten Aufruf zurückgeliefert wurde (vgl. Abb. 6.2.2). Für weitere Details wird auf die Dokumentation verwiesen[9].
Wird das Icon eines LAP im Kontrollfeld ausgewählt, so ruft das CDEV Netzwerk über einen SelectADEV-Call den 'adev'-Code des zugehörigen ADEV-Files, um diesem die Auswahl anzuzeigen.
Abb. 6.2.3: Auswahl einer Verbindung durch SelectADEV
Der 'adev'-Code liefert darauf den Kennwert der Implementierung[10], welcher im Parameter RAM festgehalten wird (siehe Abb. 6.2.3). Er wird bei der Installation auch an den 'atlk'-Code übergeben und dient beim Systemstart dem LAP Manager INIT zur Auswahl der aktiven AppleTalk-Verbindung.
Abb. 6.2.4: Deinstallation einer LAP-Implementierung
Das CDEV Netzwerk kommuniziert bei der Auswahl im Kontrollfeld auch mit der 'atlk'-Resource des ADEV-Files. Das geschieht über weitere Prozeduren zur Installation und Deinstallation der 'atlk'-Resource im System Heap. Bevor eine neue LAP-Implementierung installiert werden kann, muß das alte LAP aus dem System Heap entfernt werden. Nachdem über SelectADEV die 'adev'-Resource ausgewählt wurde, entfernt das CDEV den 'atlk'-Code des alten LAP aus dem System Heap. Da der zur Zeit installierte Code aber von seinem Resource File gelöst (detached) ist, muß sich das CDEV über einen LWrtGet-Call an den LAP Manager die Adresse des aktiven 'atlk'-Codes im System Heap besorgen (vgl. Abb. 6.2.4). Durch einen AShutDown-Call an den aktiven 'atlk'-Code wird dieser dann veranlaßt, sich mit einem LWrtRemove an den LAP Manager aus dem System Heap und dem LAPWrite Hook zu entfernen.
Nachdem der zuvor installierte LAP-Code entfernt wurde, kann über die Prozedur AInstall die 'atlk'-Resource des neuen LAP in den System Heap geladen und initialisiert werden. Damit der Code auch nach dem Schließen des Kontrollfelds im Speicher verbleibt, wird er von seinem Resource File gelöst (detached). Durch die LWrtInsert-Prozedur des LAP Managers installiert der 'atlk'-Code bei der Initialisierung seine LAPWrite-Prozedur im LAPWrite Hook.
Abb. 6.2.5: Installation des LAP-Codes
Ähnlich wie die Installation des 'atlk'-Codes bei der Auswahl im Kontrollfeld verläuft das Laden der Resource beim Systemstart. Nachdem das INIT den LAP Manager geladen und initialisiert hat, entnimmt es dem Parameter RAM den Wert des aktiven LAP und installiert es im System Heap.
Abb. 6.2.6: Installation der AppleTalk-Verbindung beim Systemstart
Jedesmal wenn die Receive-Interruptprozedur im 'atlk'-Code den Header eines Paketes gelesen hat, aktiviert sie über die Prozedur LRdDispatch den LAP Manager. Dieser ruft hierrauf den zum LAP-Typ gehörenden Protocol Handler, der das weitere Einlesen des Paketes übernimmt. An die Stelle, an der LRdDispatch gerufen wurde, wird nur zurückgekehrt, wenn der LAP Manager keinen zum LAP-Typ passenden Protocol Handler gefunden und gerufen hat (vgl. Abb. B.5.11). Im Detail wird der Aufrufmechanismus in der Implementierungsbeschreibung zum ISDNLAP in Anhang B behandelt.
Auf den ersten Blick erscheint das Konzept des LAP Managers die Implementierung und Installation eines alternativen AppleTalk-LAP wesentlich zu erleichtern. Dieser Vorteil wird jedoch durch die nachlässige Dokumentation geschmälert.
6.3 Wahl der Übertragungsart für AppleTalk-Pakete
Nachdem feststeht, daß das LAP das geeignete Protokoll zur Ersetzung ist und hierfür der LAP Manager verwendet werden soll, muß noch geklärt werden, wie und in welcher Form LAP-Pakete von der Verbindungsschicht übertragen werden können. Verschiedene Methoden hierzu werden im folgenden Abschnitt diskutiert.
6.3.1 Übertragungsprotokolle für ISDN-AppleTalk
Um Pakete über eine Leitung zu übertragen, können die verschiedensten Methoden zur Anwendung kommen. Bei der Auswahl eines adäquaten Übertragungsprotokolls sind folgende Kriterien zu berücksichtigen:
• Die Leistungsfähigkeit des Rechners[11].
• Es ist darauf zu achten, daß der anfallende Protokolloverhead möglichst gering ist.
• Der Implementierungsaufwand soll sich in Grenzen halten. Dabei ist es vorteilhaft, wenn ein Protokoll von einem Kommunikationsbaustein unterstützt wird.
• Entscheidend ist auch die Art der Schnittstelle, die zur Verfügung steht. Insbesondere, ob es sich um ein synchrones/asynchrones Interface zum Netz handelt und welche Übertragungsrate gewünscht wird. Das Übertragungsprotokoll muß an das Medium angepaßt sein.
• Die Adressierung im Netzwerk[12] und das ursprünglich verwendete Paketformat.
Der Apple Macintosh ist mit einem Zilog 8530 Serial Communications Controller ausgestattet. Dieser Baustein unterstützt folgende Datenübertragungsmodi, unter denen ein geeigentes Protokoll zur Übertragung von AppleTalk-Paketen zu wählen ist:
v AppleTalk-Pakete können asynchron übertragen werden, wie das etwa durch das Async AppleTalk geschieht. Mit den vorhandenen Schnittstellen sind jedoch nur Übertragungsraten von maximal 48 kbit/s möglich. Der größte Nachteil einer asynchronen Übertragung von Paketen ist aber der hohe Implementierungsaufwand. Für eine transparente Übertragung müssen Kontrollzeichen in den Daten „escaped“ und „geodert“ und eine Prüfsumme muß explizit errechnet werden[13].
v Nicht viel geringer ist der Aufwand, der bei einer synchronen Übertragung von Paketen durch ein BSC-Protokoll[14] zu betreiben ist. Hier übernimmt der SCC zwar die Berechnung der Prüfsumme, zur Rahmenbildung müssen jedoch den Paketen Steuerzeichen (STX, ETX, etc.) angehängt und wieder entfernt werden. Diese Rahmenbildung um den normalen LAP-Frame verursacht zusätzlichen Protokolloverhead, der beim Standard-AppleTalk nicht vorhanden ist.
v Das Standard-AppleTalk verwendet ein HDLC-ähnliches Paketformat und überträgt Pakete im HDLC-Mode des SCC mit einem intern erzeugten Takt. Da der SCC dieses Protokoll besonders gut unterstützt, entsteht kein zusätzlicher Protokolloverhead und es können auch mit dem M68000-Prozessor hohe Datenraten erreicht werden. Da ISDN-Systeme einen freien Kanal (clear channel) anbieten und einen Takt über das Netz liefern, liegt es nahe, ein HDLC-ähnliches Protokoll mit externem Takt zu implementieren. So kann auch das Paketformat unverändert übernommen werden und es ist keine zusätzliche Rahmenbildung erforderlich.
6.3.2 Der Kommunikationsbaustein im Macintosh
Alle Rechner der Macintosh-Familie sind mit einem sehr leistungsfähigen und vielfältigen Zilog 8530 Serial Communications Controller (SCC) ausgestattet:
6.3.2.1 Eigenschaften des SCC im Überblick
Die Leistungsmerkmale des SCC sind für die Implementierung der Verbindungssteuerung und der Paketübertragung von zentraler Bedeutung. Daher wird im folgenden ein kurzer Überblick über den Aufbau und die Arbeitsweise des SCC gegeben. Für detailliertere Betrachtungen wird auf das Handbuch verwiesen[15].
Der SCC besitzt zwei unabhängig voneinander verwendbare Duplex-Kanäle (Kanal A, Kanal B), über die er 2 Schnittstellen bedienen kann. Dabei ist der Modemport des Macintosh mit Kanal A und der Printerport mit Kanal B verbunden. Pro Kanal sind 32 Register (16 Write- und 16 Read-Register) zur Kontrolle und Steuerung des SCC vorhanden, von denen allerdings nicht alle zugänglich sind. Die Write-Register können leider nur beschrieben und nicht mehr gelesen werden. Von den Read-Registern sind nur 9 lesbar. Bei den Zugriffen auf die Register des SCC wird zwischen Flags und Kommandos unterschieden. Kommandos bewirken nur eine Aktion, wenn das entsprechende Bit gesetzt wird. Eine Null hat keine Wirkung.
Der Kommunikationsbaustein unterstützt verschiedene Übertragungsmodi. Dabei ist für die Verbindungssteuerung vor allem die Unterstützung von byteorientierten, synchronen Verfahren von Bedeutung. Der BSC-Mode des SCC hat folgende Merkmale:
v 1 oder 2 programmierbare SYNC-Zeichen
v 6- oder 8-Bit-SYNC-Zeichen
v Interne oder externe Zeichensynchronisation
v Automatisches Einfügen und Löschen von SYNC-Zeichen (Interframe Filling)
v Automatische Erzeugung und Überprüfung der Parität und der CRC-Prüfsumme
Durch einen speziellen HDLC-Mode wird die synchrone Übertragung von Paketen, die auch AppleTalk benutzt, unterstützt. Nachstehend werden die wesentlichen Merkmale, die in dieser Arbeit Verwendung finden, angeführt:
v Automatisches Einfügen und Entfernen von Flags zwischen aufeinander folgenden Frames (Interframe Filling)
v Adreßfelderkennung
v Automatisches Bitstuffing
v Erzeugung und Testen der CRC-Prüfsumme
v Erzeugung und Erkennung der Abbruchsequenz (mehr als 7 kontinuierliche 1-Bits)
Der SCC unterstützt verschiedene physikalische Kodierungen, von denen hier nur die NRZ- und die FM-Kodierung, wie sie AppleTalk verwendet, von Bedeutung sind. Für jeden der beiden Kanäle steht ein Baudratengenerator zur internen Erzeugung des Übertragungstaktes zur Verfügung[16]. Ein externer Takt kann über verschiedene Eingänge eingespeist werden. Bei geeigneter Kodierungen ist es möglich, den Empfangstakt aus dem ankommenden Bitstrom zurückzugewinnen (DPLL). Bei einer Taktfrequenz des SCC von 3.672 MHz werden synchron folgende Übertragungsraten erreicht:
v maximal 250 kbit/s bei interner Taktung und Verwendung der FM-Kodierung[17]
v maximal 1 Mbit/s bei Verwendung der NRZ-Kodierung und externem Takt[18]
Pro Kanal besitzt der Empfänger einen FIFO-Puffer für 3 Zeichen und den zugehörigen Status (vgl. Abb. 6.3.1). Zusätzlich existiert ein Receive-Shift-Register, in dem die ankommenden Bits zu Zeichen zusammengesetzt werden. Beim Senden wird nur ein Zeichen gepuffert. Aus diesem Puffer gelangt das Zeichen in das interne Transmit-Shift-Register, das die einzelnen Bits eines Zeichens zur Übertragung seriell ausgibt.
6.3.2.2 Der BSC-Mode des SCC
Verschiedene Protokolle zur Verbindungssteuerung arbeiten mit Steuersequenzen und Signalleitungen. Um einzelne Zeichenfolgen auf das Netz zu senden und Steuer- und Signalleitungen zu bedienen, ist der BSC-Mode des SCC sehr hilfreich. Daher wird diese Betriebsart des SCC hier kurz vorgestellt.
Um den SCC für den BSC-Mode zu initialisieren, wird zunächst über das Register 9 ein Reset des gewünschten Kanals vorgenommen. Anschließend wird dem SCC in verschiedenen Registern mitgeteilt, woher er den Takt zu beziehen hat, wieviele Bits ein Zeichen umfaßt, welche Zeichen er im Ruhezustand auf die Leitung sendet und welche aus dem Bytestrom zu filtern sind. Zusätzlich können Zeichen mit einer Parität versehen werden.
Die Zeichensynchronisation im BSC-Mode geschieht über konfigurierbare SYNC-Character, die vor jeder Zeichensequenz übertragen werden. Eine Rahmensynchronisation erhält man, indem zu Beginn eines Paketes ein SOH-Zeichen und am Ende ein ETB- bzw. ETX-Zeichen übertragen wird[19]. Das ist allerdings für unsere Zwecke nicht von Bedeutung.
Sobald der SCC initialisiert ist, sucht er im ankommenden Zeichenstrom nach einem im Write-Register 6 angegebenen SYNC-Zeichen (Hunting). Sobald ein SYNC erkannt wird, ist der SCC synchronisiert. Im BSC-Mode befindet sich der SCC nach der Initialisierung sofort im Hunt Mode. Durch das Enter Hunt Mode-Kommando kann der SCC auch explizit in den Hunt Mode gebracht werden. Ein ankommendes Zeichen wird automatisch auf eine korrekte Parität überprüft. Ein Paritätsfehler kann einen Special Condition-Interrupt auslösen. Das Paritätsbit muß beim Lesen aus dem FIFO-Puffer des SCC explizit ausgeblendet werden.
Im Ruhezustand der Übertragung sendet der SCC kontinuierlich das Zeichen, das sich im Write-Register 6 befindet. Dieser Umstand ist nützlich für die Signalisierung über Leitungszustände beim Verbindungsaufbau. Zeichen können mit verschiedenen Bitlängen und Paritäten übertragen werden. Tritt bei der Übertragung einer Zeichenfolge ein Underrun auf, d.h. sowohl der Transmit-Puffer als auch das Transmit-Shift-Register sind leer, so wird auf Wunsch eine CRC-Prüfsumme angehängt.
6.3.2.3 Der HDLC-Mode des SCC
In diesem Abschnitt wird der HDLC-Mode des SCC beschrieben, welcher für die Implementierung der Paketübertragung in AppleTalk von besonderer Bedeutung ist.
Bevor Pakete im HDLC-Mode übertragen werden können, ist eine entsprechende Initialisierung des SCC vorzunehmen. Sobald der SCC durch Setzen mehrerer Register initialisiert ist, beginnt er mit dem Senden von Flags und der Rahmensynchronisation. Die Bitsynchronisation dient zur Festlegung der Lage der einzelnen Bits im ankommenden Signal. Diese kann entweder über einen externen Takt oder durch die Rückgewinnung des Übertragungstaktes aus dem ankommenden Datenstrom erfolgen (Verwendung spezieller Kodierungen, DPLL). Letzteres wird zum Beispiel vom AppleTalk Link Access Protocol verwendet.
Zur Festlegung von Beginn und Ende eines Frames im ankommenden Bitstrom dient die Rahmensynchronisation. Sobald der SCC initialisiert ist, sucht er im ankommenden Bitstrom nach einem Flag (Hunting). Durch das Bitstuffing ist sichergestellt, daß ein Flag den Beginn eines neuen Frames anzeigt. Sobald der Baustein ein Flag erkannt hat, ist er synchronisiert. Im HDLC-Mode befindet sich der SCC nach der Initialisierung automatisch im Hunt Mode. Er kann aber auch durch das Enter Hunt Mode-Kommando explizit in den Hunt Mode gebracht werden. Dadurch wird der SCC veranlaßt, sämtliche Zeichen bis zum nächsten Flag zu ignorieren. Das ist vor allem dann nützlich, wenn während des Empfangens eines Frames ein Fehler aufgetreten ist und die restlichen Zeichen des fehlerhaften Frames verworfen werden müssen. Durch das nächste Flag wird die Rahmensynchronisation wieder hergestellt.
Die automatische Adreßerkennung erlaubt es, dem SCC eine Adresse vorzugeben. Alle Frames, deren Adresse nicht mit der gesetzten Adresse übereinstimmt, werden ignoriert. Neben einer einzelnen Adresse kann auch eine Bereichsadresse angegeben werden (Broadcast-Adresse ist $255). In den Vergleich werden dann nur die vier höherwertigen Bits der Adresse einbezogen. Die automatische Adreßerkennung wird auch von AppleTalk verwendet.
Sobald die Rahmensynchronisation erfolgt ist, kann ein Frame gesendet werden. Wenn gerade kein Frame zur Übertragung ansteht, werden vom SCC kontinuierlich Flags gesendet. In diesem Zustand ist der CRC-Generator initialisiert. Ein zu sendender Frame wird dem SCC vom Prozessor zeichenweise übergeben, indem Zeichen für Zeichen in den Transmit-Puffer geschrieben wird. Vor dem Senden eines Frames ist zu testen, ob das EOM-Bit zurückgesetzt wurde, d.h. ob der vorangegangene Frame beendet ist. Bevor ein Zeichen in den Transmit-Puffer geschrieben wird, muß sichergestellt sein, daß dieser leer ist. Das kann entweder durch Polling oder durch einen TxEmpty-Interrupt geschehen. Beim Polling wird durch Abfragen des TxBufferEmpty-Bits in Status-Register 0 geprüft, ob der Transmit-Puffer leer ist. Eventuell muß etwas gewartet werden. Dieses Vorgehen führt jedoch zu unnötigen Warteschleifen. Beim interruptgetriebenen Senden wird der SCC so programmiert, daß er jedesmal, wenn der Transmit-Puffer leer ist, einen Interrupt auslöst. Von einer Interruptserviceroutine (ISR) wird dann das nächste Zeichen in den Transmit-Puffer übertragen. So werden zwar die beim Polling entstehenden Warteschleifen vermieden, jedoch entsteht bei dieser Methode ein zusätzlicher Overhead durch die Interruptverarbeitung.
Bitstuffing auf der Sender- und Empfängerseite sowie die Generierung der Prüfsumme werden vom SCC automatisch durchgeführt. Vor dem Übertragen des letzten Zeichens eines Frames muß der Prozessor das EOM-Bit über das Write-Register 0 zurücksetzen. Wird der SCC mit keinem weiteren Zeichen versorgt, so bedeutet dies das Ende des Frames. Sobald sowohl der Transmit-Puffer als auch das Transmit-Shift-Register leer ist, betrachtet der SCC den Frame als abgeschlossen. Ist das EOM-Bit zu diesem Zeitpunkt zurückgesetzt, so wird die Prüfsumme und das abschließende Flag angefügt. Andernfalls werden nur Flags und keine Prüfsumme gesendet. Anschließend wird der CRC-Generator automatisch initialisiert und die Übertragung des nächsten Frames kann beginnen.
Beim Senden ist darauf zu achten, daß der SCC schnell genug mit Zeichen versorgt wird. Andernfalls wird sowohl das Transmit- als auch das Transmit Shift-Register leer und es tritt ein TxUnderrun-Fehler auf. Dabei wird der Frame unbeabsichtigt abgeschlossen. Um bei einem unbeabsichtigten Underrun des Transmitters das Anfügen der Prüfsumme an ein noch nicht abgeschlossenes Paket zu verhindern, ist es zweckmäßig das EOM-Bit erst vor oder unmittelbar nach der Übertragung des letzten Zeichens in den Transmit-Puffer zurückzusetzen. Ein TxUnderrun kann auftreten, wenn das Senden eines Frames, z.B durch einen Interrupt, zu lange unterbrochen wird. Durch das Fehlen der Prüfsumme wird von der Gegenstelle ein Fehler erkannt und der Frame verworfen.
Abb. 6.3.1: Zeichen und zugehöriger Status im FIFO
Das Empfangen eines Frames geschieht ebenfalls zeichenweise. Erkennt der SCC ein Zeichen, so kann das zum einen durch Polling und zum anderen durch einen Interrupt festgestellt werden. Beim Polling prüft der Prozessor anhand des RxCharacterAvailable-Bits in Status-Register 0, ob ein Zeichen angekommen ist. Ist dies der Fall, so wird über das Status-Register 1 zuerst der Status des Zeichens überprüft und dann das Zeichen gelesen (vgl. Abb. 6.3.1). Bei Ankunft eines Zeichens mit gesetztem End of Frame-Bit ist der Frame abgeschlossen. Anhand des CRCError-Bits kann nun die Gültigkeit der Prüfsumme festgestellt werden. Diese Methode erfordert eine Warteschleife, in der ständig der Status des SCC geprüft wird. Über das Write-Register 1 kann der SCC auch so programmiert werden, daß beim Empfang eines Zeichens ein Interrupt ausgelöst wird. Die entsprechende Interruptroutine prüft den Status des Zeichens und liest es ein. Dabei können verschiedene Interruptmodi verwendet werden. Tritt während des Empfangs eines Frames ein Fehler auf, so ist nach der Fehlerbehandlung das Error Reset-Bit in Register 0 zu setzen, um den Fehlerzustand aufzuheben. Die Prüfsumme wird vom SCC automatisch mitberechnet und mit der Prüfsumme am Ende des Frames verglichen. Das Ergebnis kann bei EOF dem CRCError-Bit in Read-Register 1 entnommen werden.
Mit dem SCC steht ein universeller und leistungsfähiger Kommunikationsbaustein zur Verfügung. Als Nachteil ist anzusehen, das der SCC im Vergleich zur restlichen Hardware des Macintosh etwas langsam ist. Das äußert sich darin, daß auf den SCC nur alle 2,2 µs (1.8 µs beim SCC im Macintosh II ) zugegriffen werden darf, da sich zuvor die inneren Zustände nicht stabilisiert haben. Hinderlich ist auch, daß die Write-Register des SCC nicht lesbar sind. Dadurch kann der aktuelle Inhalt nicht überprüft werden.
6.3.3 Polling und Interrupts
Es gibt zwei Methoden mit deren Hilfe die CPU mit der Außenwelt kommunizieren kann: Polling und Interrupts. Für die serielle Kommunikation ist die Interrupt-Methode von größter Bedeutung. Daher wird an dieser Stelle der Interruptmechanismus im Macintosh und im SCC kurz vorgestellt. Der M68000-Prozessor besitzt 7 Interruptebenen, wobei Ebene 7 höchste und Ebene 1 niedrigste Priorität hat[20]. Das Abarbeiten eines Interrupts kann nur von einem anderen Interrupt mit höherer Priorität unterbrochen werden.
|
Ebene |
Unterbrechendes Gerät |
|
0 |
Keines |
|
1 |
VIA |
|
2 |
SCC |
|
3 |
VIA und SCC |
|
4-7 |
Debugger-Knopf |
Abb. 6.3.2: Die Interruptebenen des Macintosh-Betriebssystems
Beim Macintosh ist für den SCC die Ebene 2 reserviert (vgl. Abb. 6.3.2). Interrupts der Ebene 1 sind dem VIA 6522-Baustein (Versatile Interface Adapter) zugeordnet. Der VIA-Baustein ist ein Mehrzweckinterfacebaustein und unter anderem für das Keyboard und, neben dem SCC, auch für die Maus zuständig[21]. VIA-Interrupts besitzen die Priorität 1 und können somit die Bearbeitung von SCC-Interrupts nicht unterbrechen.
6.3.3.1 Die Interrupts des SCC (Level-2-Interrupts)
Prinzipiell gibt es drei Arten von SCC-Interrupts[22]. Um ankommende Zeichen entgegenzunehmen löst der Kommunikationsbaustein Empfangsinterrupts aus. Diese sind durch das Write-Kontrollregister 1 folgendermaßen konfigurierbar:
v Receive Interrupt on all Characters or Special Condition: Jedes ankommende Zeichen löst einen Interrupt aus.
v Receive Interrupt on first Characters or Special Condition: Nur das jeweils erste Zeichen eines Frames löst einen Interrupt aus. Bei Verwendung dieses Interrupts müssen die restlichen Zeichen des Frames durch Polling abgeholt werden. Das spart den Mehraufwand durch die Interruptverarbeitung. Dieser Mode ist insbesondere bei Verwendung von DMA von Bedeutung. Das erste Zeichen löst die Entgegennahme der restlichen Zeichen aus.
v Receive Interrupt on Special Condition only: Ein Interrupt wird nur angefordert, wenn das Ende eines Frames erreicht oder ein Überlauf aufgetreten ist. Die Ankunft fehlerfreier Zeichen innerhalb eines Frames löst keinen Interrupt aus.
Für langsame Übertragungsraten besitzt der SCC die Möglichkeit Sendeinterrupts auszulösen, sobald der Transmit-Puffer leer ist. Eine ISR überträgt dann das nächste Zeichen an den SCC und beendet den Interrupt. Weiter bietet der SCC die Möglichkeit in zahlreichen Situationen Interrupts auszulösen. Diese externen und Status-Interrupts können bei folgenden Ereignissen ausgelöst werden:
v Eine Statusänderungen der Handshake-Signale DCD und CTS hat stattgefunden. Beim Macintosh Plus werden diese Interrupts für die Kontrolle der Maus verwendet.
v Eine Abort-Sequenz (1111111…1) wurde empfangen.
v Das Ende eines gesendeten Frames ist erreicht (TxUnderrun/EOM).
v Bei Erreichen bzw. Verlust der Rahmensynchronisation (Sync/Hunt).
v Der Zähler im Baudratengenerator ist abgelaufen.
Über das Master Interrupt Enable-Bit (MIE) im Write-Register 9 wird festgelegt, ob vom SCC Interrupts angefordert werden. Falls dieses Bit zurückgesetzt wird, fordert der SCC keine Interrupts an. Im Write-Register 1 des SCC können Sende-, Empfangs- und External/Statusinterrupts unabhängig voneinander zugelassen werden. Darüber hinaus werden über Register 15 die gewünschten External/Statusinterrupts näher spezifiziert. Ein bestimmter Interrupttyp kann vom SCC nur angefordert werden, wenn sowohl das MIE-Bit gesetzt als auch der Interrupt selbst zugelassen ist. Die Zulassung von Interrupts kann für beide Ports unabhängig geschehen.
6.3.3.2 Die Behandlung von Schnittstellen-Interrupts
Zunächst wird der sogenannte Level-2 Interrupt Handler aufgerufen. Er ist Bestandteil des ROM-BIOS, das einen großen Teil des Macintosh-Betriebssystems enthält. Dieser Handler, der aus etwa 20 Zeilen Assembler Code besteht, bestimmt die Ursache des Interrupts und springt die betreffende Interruptserviceroutine als Unterprogramm an. Die Adresse der ISR entnimmt er der Level-2 Interrupt Dispatch-Tabelle (Abb. 6.3.3).
Level2IntTable = RECORD { The Level-2 Interrupt Dispatch Table }
ChannelBTBufferempty: Ptr;
ChannelBESchange: Ptr;
ChannelBRavailable: Ptr;
ChannelBScondition: Ptr;
ChannelATBufferempty: Ptr;
ChannelAESchange: Ptr;
ChannelARavailable: Ptr;
ChannelAScondition: Ptr;
END;
Abb. 6.3.3: Die Pascal-Struktur der Level-2 Interrupt Dispatch Table
Diese Tabelle ordnet jedem Interrupttyp des SCC, nach Port getrennt, eine ISR zu. Eine neue ISR kann in dieser Tabelle durch Eintragung ihrer Adresse installiert werden. Die Adresse, an der diese Tabelle sich im Speicher befindet, ist der globalen Betriebssystemvariable Lvl2DT zu entnehmen. Bei der Bearbeitung eines SCC-Interrupts entsteht ein Overhead von 340–354 Taktzyklen, je nach Port, der den Interrupt auslöst. Diese Zeit ergibt sich aus dem Interruptzyklus des Prozessors von 44 Taktzyklen und der Zeit für die Abarbeitung des Level-2 Interrupt Handlers von 296–310 Taktzyklen, je nach Port. Der Interrupt Handler verbraucht also bei einer Übertragungsrate von 64 kbit/s und einem Prozessortakt von 8 MHz bereits über 1/3 der für das Einlesen eines Zeichens zur Verfügung stehenden Zeit[23].
Bevor die ISR die Kontrolle wieder an den Level-2 Interrupt Handler zurückgibt, teilt sie dem SCC durch Setzen des ResetHIUS-Bits (Reset Highest Interrupt Under Service) in Write-Register 0 mit, daß der betreffende Interrupt abgearbeitet wurde. Danach kann der SCC erneut Interrupts anfordern.
6.3.3.3 Polling versus Interrupt-getriebener Übertragung
Die Entscheidung, ob bei einer Implementierung das Senden eines Frames durch Polling oder über Interrupts erfolgt, hängt wesentlich von der Übertragungsrate und der zur Verfügung stehenden Prozessorleistung ab:
• Bei, im Vergleich zur Übertragungsrate, geringer Prozessorleistung[24] (z.B. M68000) ist Polling günstiger, da unnötiger Overhead bei der Behandlung des Interrupts vermieden wird. Hingegen ist die überschüssige Leistung, die in einer Warteschleife verloren geht, relativ gering.
• Bei Prozessoren höherer Leistungsfähigkeit (z.B. M68020/30/40) ist die Interruptmethode effizienter, da trotz des Interruptoverheads genügend Zeit verbleibt, andere Aufgaben (z.B. für das Betriebssystem) zu erfüllen.
Ebenso wie beim Senden kann beim Empfangen für jedes Zeichen ein Interrupt durch den SCC ausgelöst werden. Eine derartige Entgegennahme von Zeichen ist jedoch nur bei niedrigen Übertragungsraten gerechtfertigt, da bei höheren Übertragungsraten der Overhead durch das Interrupt Dispatching zu viel Zeit in Anspruch nimmt. Ein Drittel der Zeit, die nach Auslösung des Interrupts verbleibt, um ein Zeichen entgegenzunehmen, geht bei einer Übertragungsgeschwindigkeit von 64 kbit/s und einem M68000 Prozessor mit 8 MHz Taktfrequenz durch das Interrupt Dispatching verloren.
Da zur Implementierung des ISDN-AppleTalk ein Macintosh Plus mit einem M68000 Verwendung[25] findet und die Übertragungsrate bei 64 kbit/s und höher liegt, ist folgendes Vorgehen ratsam:
v Gesendet werden Pakete, indem zwischen den Zeichen jeweils eine bestimmte Zeit gewartet wird, bis der Transmit-Puffer leer ist. Die Sendeprozedur wird während der Übertragung nicht verlassen.
v Das erste Zeichen eines ankommenden Paketes löst einen Interrupt aus. Danach wird durch Pollen Zeichen für Zeichen von der Schnittstelle entgegengenommen. Der Interrupt wird erst beendet, wenn das Paket vollständig eingelesen ist.
Ein zeichenweises Einlesen eines AppleTalk-Paketes per Interrupt ist auch deshalb nicht möglich, da Protocol Handler stets eine Anzahl von mehreren Zeichen zu lesen versuchen. Würde eine Empfangsroutine nach einem gelesenen Zeichen zum Protocol Handler zurückkehren, so würde dieser einen Fehler vermuten[26].
6.3.4 Vollduplex- versus Halbduplex-Übertragung
Eine Übertragung zwischen zwei Stationen findet üblicherweise entweder halbduplex oder vollduplex statt. Während bei der Halbduplex-Übertragung nur jeweils entweder gesendet oder empfangen wird, müssen bei der Vollduplex-Übertragung gleichzeitig Daten gesendet und empfangen werden (vgl. Abb. 6.3.4). Daher erfordert diese Art der Übertragung aufwendigere Übertragungs- und Empfangsroutinen.
Abb. 6.3.4: Der Vollduplex- und Halbduplex-Betrieb
Die Pakete des ISDNLAP werden aus folgenden Gründen halbduplex übertragen:
• Bei einer Vollduplex-Übertragung von Paketen müssen gleichzeitig Zeichen von der Schnittstelle gelesen und gesendet werden. Dieser Vorgang ist sehr zeitkritisch, da zum einen ein Overrun des Receive-FIFO-Puffers und zum anderen ein Underrun des Transmit-Registers verhindert werden muß. Bei der Prozessorleistung des M68000 und einer Übertragungsrate von 64 kbit/s und mehr ist die Implementierung in einer Hochsprache wie Pascal mit Schwierigkeiten verbunden. Der Code müßte unter Umständen in Assembler implementiert werden.
• Normalerweise schreibt das LAP ein Paket nach dem Einlesen des Kopfes direkt in den Puffer des Klienten. Da sich übergeordnete Schichten unter Umständen viel Zeit lassen können, ein ankommendes Paket zu verarbeiten, müßten bei Vollduplex-Betrieb Pakete gepuffert werden. Durch die Pufferung wird aber ein Umkopieren der Pakete notwendig. Erst wenn kein Frame zu senden ist, kann ein Paket an die Klienten weitergereicht werden. Hierdurch geht aber ein wesentlicher Vorteil der Parallelisierung des Sendens und Empfangens wieder verloren.
• Das Standard-LAP des AppleTalk arbeitet mit einem CSMA/CA-Algorithmus, um Kollisionen auf dem Netz zu verhindern. Pakete können daher nicht gleichzeitig in beide Richtungen übertragen werden. Alle AppleTalk-Protokolle basieren somit auf Halbduplex-Verbindungen. Eine Vollduplex-Übertragung von Paketen auf der Link-Ebene würde keine Steigerung der Übertragungsleistung bewirken, da die übergeordneten Protokolle halbduplex arbeiten.
• Da in ISDN-Systemen nur Punkt-zu-Punkt-Verbindungen auf getrennten Sende- und Empfangsleitungen unterstützt werden, ist im ISDNLAP keine Zugriffskontrolle in Form eines CSMA/CA o.ä. notwendig. In einer zukünftigen Version für Mehrpunktverbindungen wird ein MAC-Algorithmus aber wieder benötigt.
• Der Verlust eines Paketes im interruptgetriebenen Halbduplex-Betrieb ist nur in folgenden Fällen möglich:
v Wenn während des Sendens Receive-Interrupts gesperrt sind und der Abstand, in dem beide Stationen zu senden beginnen, geringer ist als die Laufzeit eines Zeichens auf den Netz[27]. Da höhere Protokolle dialogorientiert arbeiten, ist diese Situation nur bei unsynchronisiertem Zugriff auf untere Schichten denkbar.
v Sind während des Sendens Receive-Interrupts zugelassen, so kann die Übertragung eines Paketes durch einen Interrupt unterbrochen werden. Tritt durch die entstehende Verzögerung ein Underrun des Transmitters auf, so wird das gesendete Paket wiederholt.
Zur Übertragung von AppleTalk-Paketen über ISDN-Kanäle wird mit Hilfe des LAP Managers das Link Access Protocol im AppleTalk Protocol Stack ersetzt. Dabei werden Pakete im HDLC-Mode des SCC halbduplex übertragen. Sowohl beim Senden als auch beim Empfangen eines Paketes wird der SCC gepollt.