Anhang C: Hilfprogramme für ISDNLAP
C.1 Implementierung eines NameServers
Für die Adressierung im ISDN-AppleTalk wird ein NameServer als Macintosh-Applikation implementiert. Bei der aktuellen Version des NameServer handelt es sich noch nicht um eine „fertige Applikation“, sondern vielmehr um ein Demonstrationsprogramm, anhand dessen gezeigt werden soll, wie die Adressierung in einem leitungsvermittelnden System gehandhabt werden kann.
Abb. C.1.1: Das Icon des NameServers auf dem Desktop
Die vorliegende Implementierung eines NameServers hat daher noch keine Funktionen zum Testen von Einträgen auf deren Gültigkeit. Der NameServer erkennt also noch nicht, wenn eine registrierte Station unerwartet inaktiv wurde. Dazu müßten die einzelnen Stationen periodisch angewählt und die Gültigkeit der Einträge geprüft werden. Die vorliegende Version erfüllt folgende Aufgaben:
• Registrierung von Node IDs und Rufnummern, deren manuelle Verwaltung und das Auskunftgeben über eine Rufnummer zu einer Node ID.
• Registrierung von Names Table-Einträgen, deren manuelle Verwaltung und die Bearbeitung von Name LookUps.
Die beschriebene NameServer-Applikation besteht funktionell aus drei Teilen:
v Den Sende- und Empfangsroutinen, die denen des ISDNLAP ähnlich sind. Der Unterschied liegt lediglich darin, daß im NameServer Pakete als Ganzes gelesen werden und der Zugriff auf globale Variablen problemlos ist. Zudem können die Routinen einer Applikation leichter getestet werden.
v Den Prozeduren zur Verwaltung der Benutzeroberfläche. Dabei findet vor allem der List Manager Verwendung. Hierzu gehört die Main Event Loop und die Verarbeitung von Events.
v Schießlich enthält das Programm Routinen, zum Einfügen, zur Suche und zum Löschen von Node ID- und Names Table-Einträgen in den jeweiligen Listen.
Beim Starten der Applikation durch Anklicken des NameServer-Icons wird zunächst durch die Prozedur Initialize die Macintosh-Toolbox initialisiert. Anschließend wird die Menu Bar aufgebaut und angezeigt und einige Statusvariablen gesetzt. Danach öffnet das Hauptprogramm mit der Prozedur OpenNameServer das NameServer-Fenster (vgl. Abb. C.1.2) und erzeugt die Listen zur Aufnahme der NBP- und Node ID-Einträge. Hierauf wird die Prozedur UpdateLists zum Zeichnen des NameServer-Fensters gerufen. Bevor der NameServer in die Main Event Loop eintritt, wird durch Aufruf von InitSCCStuff der Port B für die Entgegennahme eines Anrufs vorbereitet (vgl. ISDNLAP) und die VBL-Task für den Verbindungsabbau installiert.
In der Main Event Loop wird nun kontinuierlich die Prozedur SystemTask gerufen, um die Ausführung von Deskaccessories zu ermöglichen. Danach werden die Statusvariablen NodeHere und NameHere geprüft. Falls notwendig, wird den Listen des NameServers ein Eintrag hinzugefügt. Zeigt anschließend die Funktion GetNextEvent an, daß ein Event vorliegt, so er von der Prozedur HandleEvent behandelt.
Abb. C.1.2: Dialogbox zur Anzeige und Manipulation von Node IDs und Names Table-Einträgen
Abgebrochen wird die Schleife, wenn die Variable First durch Auswahl des Quit-Items im Menü gesetzt wird. Hierauf schließt die Prozedur CloseNameServer das NameServer-Fenster und gibt die Listen frei. Zusätzlich wird mit HangUp eine eventuell bestehende Verbindung abgebrochen und die alte Interruptserviceroutine (ISR) wieder in Level2IntTable installiert.
C.1.1 Verwaltung der Node IDs
C.1.1.1 Registrierung einer Node ID mit Nummer
Wird eine Verbindung zum NameServer aufgebaut, so entnimmt dieser der Anschlußkennung des ankommenden Anrufs die Rufnummer der Gegenstation. Dazu wird von ReceiveCall die Prozedur FilterNumber gerufen, die Rufnummern extrahiert und führende Nullen entfernt. Empfängt darauf der NameServer über ReceiveFrame ein ENQ-Paket, so wird von der Prozedur ReceiveLinkMgnt die Node ID der anrufenden Station in der Variablen HisAddress festgehalten und zusammen mit der Rufnummer in die globale Variable NodeToInsert kopiert. Ein Zwischenspeichern ist deshalb erforderlich, da die Behandlung des ENQ-Paketes im Interrupt stattfindet. Hierbei darf zur Erzeugung eines neuen Eintrags der Memory Manager nicht verwendet werden[1]. Das Einfügen der zwischengespeicherten Node ID und der Rufnummer in die dynamische Liste geschieht in der Main Event Loop.
PROCEDURE FilterNumber(VAR MyNumber: Str255);
Danach prüft ReceiveLinkMgnt anhand der Funktion NodeExists, ob die Node ID des ENQ-Paketes dem NameServer bekannt ist. Liefert die Funktion TRUE, so wird die Node ID bereits von einem anderen Knoten verwendet und der NameServer sendet ein ACK-Paket mit dieser Node ID an die rufende Station. Damit auch die Node ID des NameServers eindeutig bleibt, enthält das ACK-Paket die Node ID des NameServers, falls die gesuchte Node ID nicht gefunden wird.
FUNCTION NodeExists(Entry: NodeEntry): Boolean;
Die Funktion NodeExists durchläuft auf der Suche nach einer Node ID die Liste mit den Einträgen und Rufnummern. Wird die gesuchte Node ID gefunden, so prüft NodeExists, ob die Rufnummer der gefundenen Node ID mit der Rufnummer des gesuchten Eintrags übereinstimmt. Ist das der Fall, so ist dieser Knoten bereits registriert. Andernfalls ist auf dem Netz ein Knoten vorhanden, der zwar dieselbe Node ID aber eine andere Rufnummer besitzt. Damit ist die gesuchte Node ID nicht eindeutig und NodeExists liefert TRUE. Wird kein Eintrag gefunden, so liefert die Funktion FALSE. Zusätzlich wird das Flag NodeHere, welches die Main Event Loop veranlaßt die Node ID mit AddNode in die Liste aufzunehmen, entsprechend gesetzt.
C.1.1.2 Auskunft über eine Node ID
Empfängt die Prozedur ReceiveLinkMgnt über ReceiveFrame ein FND-Paket, so durchsucht sie mit FindNumber die Liste der Node ID-Einträge. Anschließend sendet sie mit Hilfe der Prozedur Transmit ein RND-Paket, das die Rufnummer des gesuchten Knotens enthält, an den anfragenden Knoten.
FUNCTION FindNumber(Node: byte): Integer;
FindNumber durchläuft auf der Suche nach der Rufnummer zu einer Node ID die Liste mit den NodeEntry-Einträgen. Wird eine Node ID gefunden, so kopiert FindNumber die zugehörige Rufnummer in outgoingpacket. Wird die gesuchte Node ID nicht gefunden, so wird die Rufnummer des NameServers zurückgegeben. Als Funktionsergebnis liefert FindNumber die Länge der gefundenen Rufnummer zurück.
C.1.1.3 Verwaltungsfunktionen
Der NameServer verwendet zur Darstellung der Liste mit den Node ID-Einträgen im NameServer-Fenster den List Manager. Zu experimentellen Zwecken kann diese Liste mit Hilfe von Befehlen aus dem NameServer-Menü manipuliert werden.
Um der Liste einen neuen Eintrag hinzuzufügen, wählt der Benutzer im NameServer-Menü den Punkt „Insert Node ID“. Hierauf wird die Prozedur InsertNewNode gerufen, die mit GetNode einen Dialog zur Eingabe eines Node ID-Eintrags zeigt (Abb. C.1.3).
Abb. C.1.3: Dialogbox zur Manipulation von Node ID und Rufnummer
Nach Eingabe von Node ID und Rufnummer wird der Eintrag mit AddNode in die Liste der Node IDs eingefügt. Um die Veränderung in dieser Liste auch am Bildschirm anzuzeigen, wird UpdateLists gerufen.
Bereits in der Liste vorhandene Einträge können durch einen Doppelklick editiert werden. Dabei wird die Prozedur ShowNodeInfo gerufen, die den Eintrag in obiger Dialogbox anzeigt. Mit UpdateLists und ChangeNodeID wird eine Änderung im Fenster und in der Liste wirksam. Das Löschen eines Node ID-Eintrags geschieht durch Auswahl eines Eintrags in der Liste mit der Maus und dem Menüpunkt „Delete Selection“. Dabei wird die Prozedur DeleteSelection gerufen und, je nach Auswahl, DeleteName oder DeleteNode ausgeführt. Die manuelle Modifikation von Node ID-Einträgen ist vor allem zum Testen des NameServers nützlich. Darüber hinaus können auf diese Weise aber auch Geräte, die über eine ISDN-AppleTalk-Brücke erreichbar sind, dem ISDN-AppleTalk bekannt gemacht werden.
C.1.2 Verwaltung von Names Table-Einträgen
C.1.2.1 Registrierung eines Names Table-Eintrags
Empfängt der NameServer ein Datenpaket, so prüft er zunächst, ob es sich um ein LkUp-Paket handelt. Ist das der Fall, so hält er in der Variablen NameToInsert den Inhalt des LkUp-Paketes fest. Durch UnPackName wird dem Paket der Namenseintrag entnommen. Das Zwischenspeichern des Paketinhalts ist notwendig, da die Pakete im Interrupt behandelt werden und somit beim Einfügen in das Names Directory des Servers kein Menory Manager verwendet werden darf. Ist das Flag NameHere durch die Funktion NameExists gesetzt worden, so wird der neue Names Table-Eintrag in der Main Event Loop durch AddName in das Names Directory des NameServers aufgenommen. Ist ein Eintrag bereits vorhanden, so sendet der NameServer ein LkUpReply-Paket an die Gegenstation.
PROCEDURE AddName(VAR Entity: MyNamesTableEntry);
Beim Eintragen von Namen ist zu beachten, daß Server sich nicht unter der Socket-Adresse des Session Service Socket (SSS), sondern unter der Adresse des Session Listening Socket (SLS) registrieren. Beim Einfügen durch die Prozedur AddName muß also der Typ des Gerätes geprüft und die Socket-Adresse entsprechend verändert werden. Bei AFPServern genügt es, die Nummer des SLS um eins zu dekrementieren. Durch Setzen der Variablen Registered muß beim Eintragen eines Namens mit AddName verhindert werden, daß bei mehreren hintereinander folgenden LkUp-Paketen mit demselben Inhalt nach dem Registrieren ein LkUpReply-Paket gesendet wird. Beim Aufbau jeder neuen Verbindung wird die Variable wieder zurückgesetzt.
C.1.2.2 Behandlung eines Name LookUps
Werden LkUp-Pakete nicht zur Registrierung, sondern zur Suche nach benannten Einträgen auf dem Netzwerk verwendet, so enthalten diese normalerweise Wildcards[2]. Von der Prozedur NameExists wird daher der Inhalt des Paketes dahingehend überprüft und entsprechend Flags für die Auswertung des Names Directories gesetzt. Da das NBP sowohl für die Registrierung als auch zur Suche von Namen LkUp-Pakete verwendet, kann anhand des Pakettyps allein nicht zwischen diesen Situationen unterschieden werden. Pakete zur Suche können allerdings daran erkannt werden, daß sie in Namen Wildcards enthalten. Derartige LkUp-Pakete dürfen nicht in das Names Directory aufgenommen werden.
FUNCTION NameExists(VAR Entity: MyNamesTableEntry): Boolean;
NameExists durchläuft das Names Directory des Servers und vergleicht die Einträge mit dem Inhalt des Paketes, der als MyNamesTableEntry übergeben wird. Findet sich ein passender Eintrag und wurde der Inhalt des LkUp-Paketes nicht zuvor registriert (Registered), so bereitet NameExists ein LkUpReply-Paket vor und sendet es. Bei jedem gefundenen Eintrag wird dabei das Enumeratorfeld des Antwortpaketes erhöht, damit der Empfänger die Antwortpakete leichter unterscheiden kann.
Da das NBP mehrere Name LookUps gleichzeitig starten kann, müssen für eine eindeutige Zuordnung der Antwortpakete zu einem Name LookUp die LkUpReply-Pakete dieselbe NBP ID besitzen, wie das beantwortete LkUp-Paket. Hat NameExists die Liste durchlaufen und keinen passenden Eintrag gefunden, so wird der Eintrag, sofern es sich nicht um ein Wildcard handelt, in die Tabelle aufgenommen (vgl. C.1.2.1).
C.1.2.3 Verwaltungsfunktionen
Ähnlich, wie Node IDs und Rufnummern, können auch die Names Table-Einträge manipuliert werden. Hinzufügen läßt sich ein Eintrag durch Auswahl des Menüpunkts „Insert Entity“. Dabei wird die Prozedur InsertNewEntity gerufen, die eine Dialogbox zur Eingabe des neuen Names Table-Eintrags zeigt und nach der Eingabe den Namen mit AddName in das Names Directory des Servers einfügt.
Abb. C.1.4: Dialogbox zur Manipulation von Names Table-Einträgen
Editiert wird ein Eintrag durch einen Doppelklick mit der Maus auf den Namen in der Liste (siehe Abb. C.1.2). Hierauf wird die Prozedur ShowEntityInfo gerufen, die den ausgewählten Eintrag der Liste entnimmt und in der Dialogbox aus Abb. C.1.4 anzeigt. Nach einer Modifikation kann der Eintrag in die Liste zurückgeschrieben oder aber mit „Cancel“ abgebrochen werden. Gelöscht wird ein Eintrag, indem er in der Liste der Namen (Obere Liste im Fenster der Abb. C.1.2) mit der Maus ausgewählt wird, worauf dieser invertiert erscheint. Durch den Menüpunkt „Delete Selection“ wird der ausgewählte Eintrag dann gelöscht.
Der NameServer hat gezeigt, daß ein zentraler Steuerrechner die Abbildung der Adressierung eines Bussystems auf ein leitungsvermittelndes System ermöglicht. Dazu werden nur wenige zusätzliche Verbindungen benötigt. Die gegenwärtige Version dient nur der Demonstration des Prinzips. Um die Gültigkeit von Einträgen jederzeit gewährleisten zu können, muß der NameServer noch um Verwaltungsfunktionen ergänzt werden.
C.2 Reduzierung des Verkehrs beim Remote Disk Access
Ein Austausch der LINK-Ebene im AppleTalk Protocol Stack ermöglicht den Zugriff von AppleTalk-Workstations auf AppleShare-Fileserver über ISDN-Kanäle. Solange sich nur eine Workstation als Klient am Server registriert und eine Sitzung mit diesem unterhält, ist der Remote Disk Access über AppleShare problemlos. Haben jedoch mehrere Stationen den Wunsch, die Dienste eines Fileservers in Anspruch zu nehmen, so entstehen Probleme:
Durch den Austausch von Kontrollpaketen des AFP und des ASP entsteht ein reger Verkehr auf der Leitung, so daß bei einem Timeout der Verbindungssteuerung von 10 Sekunden und mehr eine Verbindung nicht mehr abbricht. Somit führt der Zugriff einer Station zur Monopolisierung des Fileservers. Wollen weitere Stationen zugreifen, so ist die Leitung zum Fileserver ständig besetzt und der Zugriff blockiert. Damit mehrere Workstations den Server nutzen können, muß ein Weg gefunden werden, die Anzahl der Kontrollpakete einer AFPSession zu reduzieren und somit auch die Anzahl und die Dauer der notwendigen Verbindungen zum Server zu vermindern.
C.2.1 Die Überwachung einer AFPSession
AppleShare nutzt für den Zugriff einer Workstation auf einen Server das AppleTalk Filing Protocols (AFP). Das AFP wiederum ist ein Klient des AppleTalk Session Protocols (ASP). Beide Protokolle befinden sich in der Workstation in einem Treiber .XPP. Beim AFPServer sind diese Protokolle in der Serverapplikation integriert.
Greift nun ein Klient über AppleShare auf einen Server zu, so wird beim lokalen Installieren der abgesetzten Platte eine ASPSession eröffnet. Um festzustellen, ob die Gegenseite noch erreichbar ist, werden für die Dauer der Session sogenannte Tickle-Pakete zwischen dem Server und der Workstation ausgetauscht. Dabei handelt es sich um ATP-Pakete vom SPCmd-Typ Tickle. Von der Workstation sind diese Pakete an den SLS-Socket des Servers und vom Server an den WSS-Socket der Workstation gerichtet[3]. Tickle-Pakete enthalten als Information in ihrem Header den Typ Tickle im SPCmdType-Feld, die Session ID, sowie zwei ungenutzte Bytes. Realisiert wird der Austausch von Tickle-Paketen, indem jede Seite eine ATP-Transaktion mit unendlich vielen Retries und einem Timeout von 30 Sekunden startet (vgl. Abb. C.2.1).
Abb. C.2.1: Schematischer Ablauf der Tickle-Transaktionen
Jedes über die Session von der Gegenseite empfangene Paket setzt den Timeout zurück. Dabei ist nicht entscheidend, ob es sich um ein Tickle-Paket handelt oder nicht. Erhält eine Seite von der Gegenstation 2 Minuten ($1C20 Ticks) lang kein Paket, so wird angenommen, daß diese nicht mehr erreichbar ist und die Session wird beendet.
Um die Anzahl der Anrufe beim Server in einem leitungsvermittelnden Netzwerk zu reduzieren, ist es notwendig, diese Timeouts sowohl im Server als auch in der Workstation zu verlängern. Leider sind diese Zeitkonstanten nicht in einer Resource abgelegt und somit nicht ohne weiteres zu ändern. Durch Hilfsmittel, wie den MacNosy[4] und TMON, ist es jedoch möglich, diese Konstanten im Programmcode zu lokalisieren und zu verändern. Der zu modifizierende Code ist sowohl in der Serverapplikation als auch im .XPP-Treiber der gleiche, lediglich die Adressen sind verschieden. Ersetzt werden müssen die Konstanten $1C20 (Ticks) und 30 (Sekunden) durch entsprechend höhere Werte (vgl. Abb. C.2.2).
2F2: 47FA 05B6 10008AA LEA data6,A3
2F6: 20CB ' .' MOVE.L A3,(A0)+
2F8: 30BC 1C20 '0.. ' MOVE #$1C20,(A0)
2FC: 41EA 0074 'A..t' LEA 116(A2),A0
300: A033 '.3' _VInstall
302: 7000 'p.' MOVEQ #0,D0
304: 157C 0002 0002 '.|....' MOVE.B #2,2(A2)
54A: 0C40 FFA5 '.@..' lar_2 CMPI #-91,D0
54E: 6728 1000578 BEQ.S lar_3
550: 357C 1C20 007E '5|. .~' MOVE #$1C20,126(A2)
556: 0C28 00FC 001B '.(....' CMPI.B #252,27(A0)
55C: 66E8 1000546 BNE lar_1
55E: 6100 044C 10009AC BSR proc36
84A: 1428 0020 '.(. ' lbd_1 MOVE.B 32(A0),D2
84E: B42A 000A '.*..' CMP.B 10(A2),D2
852: 6618 100086C BNE.S lbd_2
854: 357C 1C20 007E '5|. .~' MOVE #$1C20,126(A2)
85A: 1228 0012 '.(..' MOVE.B 18(A0),D1
85E: 5301 'S.' SUBQ.B #1,D1
860: 670E 1000870 BEQ.S lbd_4
2BA: 425B 'B[' CLR (A3)+
2BC: 429B 'B.' CLR.L (A3)+
2BE: 429B 'B.' CLR.L (A3)+
2C0: 36FC 001E '6...' MOVE #30,(A3)+
2C4: 36FC FFFF '6...' MOVE #$FFFF,(A3)+
2C8: 47E8 0012 'G...' LEA 18(A0),A3
2CC: 16FC 0005 '....' MOVE.B #5,(A3)+
Abb. C.2.2: Disassemblierter Code des .XPP-Treibers
Beim AppleShare-Server sind dies die Adressen $26A4, $292C und $2BD6 für den Timeout von 2 Minuten und $28FA für den Timeout der Transaktion. Eine Änderung dieser Timeouts bewirkt natürlich auch, daß durch den Server und den Klienten das „Sterben“ der Gegenseite entsprechend später erkannt wird.
C.2.2 Das Updaten des Directories
Mehr noch als die Tickle-Transaktionen verursacht der Mechanismus zum Aktualisieren der lokalen Kopie des Server-Directories Verkehr auf dem Netzwerk. AppleShare erlaubt den gleichzeitigen Zugriff mehrerer Klienten auf einen Server. Löscht nun ein Klient eine Datei auf dem Server oder benennt er sie um, so muß diese Änderung im Directory des Server-Volumes den anderen Klienten angezeigt werden. Das geschieht, indem jeder Klient im Abstand von 10 Sekunden beim Server anfrägt, ob eine Änderung eingetreten ist. Bei einer Änderung erhält der Klient vom Server einen Update des Directories. Da ein Verbindungsaufbau nach X.21 bis zu mehreren Sekunden dauern kann und nach der Übertragung eines Paketes die Verbindung erst mit einer Verzögerung wieder abgebaut wird, bricht unter Umständen eine Verbindung zum Server nicht mehr ab. Dadurch ist der Server ständig besetzt und anderen Klienten wird der Zugriff auf den Server unmöglich gemacht. Auch hier muß die Zeit zwischen den Kontrollpaketen verlängert werden.
Realisiert wird dieser Mechanismus dadurch, daß der Treiber AFPTranslator[5], der Filesystem-Befehle in AFP-Aufrufe umsetzt, im Driver Header einen DrvrDelay von einer Sekunde ($3C Ticks) besitzt. Dadurch wird er vom Betriebssystem jede Sekunde einmal gerufen. Bei jedem zehnten Control-Aufruf mit dem CSCode 65 wird dann ein Paket an den Server geschickt, um festzustellen, ob sich am Server eine Änderung ergeben hat (Abb. C.2.3). Der Server antwortet entsprechend.
8C 26 01 00 13 FC 99 03 60 01 35 58 02 00 00 10 .....H.&......`.
11 00 FF FF 00 48 5X....
26 8C 01 00 17 99 FC 03 90 00 35 58 00 00 00 00 .H..Q...0.&.....
00 48 EB DF 51 02 01 08 30 00 ....5X....
8C 26 01 00 0D FC 99 03 C0 01 35 58 02 00 00 10 .&........5X....
Abb. C.2.3: Pakete zur Anfrage am AFPServer
Um die Zeitabstände zwischen den Kontrollpaketen zu verlängern, muß der Wert von DrvrDelay im Driver Header geändert werden. Dieser Wert, der die Anzahl der Ticks zwischen zwei Aufrufen des AFPTranslators festlegt, beträgt $003C, was 60 Ticks oder einer Sekunde entspricht. Eine Änderung im Driver Header läßt sich leicht mit ResEdit[6] vornehmen. Hat man dies durchgeführt, so wird man feststellen, daß der Treiber dennoch jede Sekunde gerufen wird. Die Ursache liegt darin, daß der Treiber selbst nach jedem Aufruf die Zeit neu setzt. Also muß auch der Code des Treibers modifiziert werden. Mit MacNosy läßt sich die Stelle lokalisieren (Abb. C.2.4).
350: 6606 1000358 BNE.S lau_1
352: 08AA 0001 0616 '......' BCLR #1,$616(A2)
358: 337C 003C 0022 '3|.<." lau_1 MOVE #60,34(A1)
35E: 302A 0624 '0*.$' MOVE $624(A2),D0
362: 6700 0108 100046C BEQ com_19
366: 08EA 0000 0616 '......' BSET #0,$616(A2)
Abb. C.2.4: Patch im Code des AFP-Translators
Das Verlängern der Perioden zwischen den Aufrufen des AFPTranslators hat zur Folge, daß Änderungen im Directory des Servers von den Klienten entsprechend später erkannt werden. Komplikationen treten dadurch nicht auf, da bei Aktionen, die über das Anzeigen des Server-Directories hinaus gehen, das lokale Directory erneuert wird.
Durch das Verlängern der Zeitabstände zwischen den Kontrollpaketen wird der Zugriff von mehreren Stationen auf einen zentralen Server ermöglicht. Dennoch sind Situationen denkbar, in denen weiterhin eine Monopolisierung des Servers eintreten kann[7].
C.3 Eine Brücke für den Druckerzugriff
Neben dem Remote Disk Access ist das Drucken eine weitere wichtige Funktion im LAN. In lokalen Netzwerken befinden sich oft mehrere verschiedene Drucker. Im Falle von AppleTalk sind das LaserWriter und ImageWriter. Beide sind netzwerkfähig, ihre Netzwerksoftware ist aber fest im ROM installiert, so daß keine Möglichkeit besteht, alternative Netzwerk-Treiber zu laden. Da ein Tausch des ROM oder der Hardware zu aufwendig ist, werden Drucker über eine Brücke und einen AppleBus angebunden.
Die Aufgabe einer Brücke besteht darin, eine Verbindung zwischen zwei Netzwerken zu schaffen. Dabei ist zu unterscheiden, ob es sich bei diesen Netzen um zwei gleichartige Netze mit gleichen Leistungsmerkmalen und gleicher Topologie handelt oder nicht[8]. Die Brücke nimmt vom einen Netzwerk Pakete entgegen, konvertiert diese gegebenfalls und leitet sie an das andere Netz weiter. Die für ISDN-AppleTalk implementierte Brücke verbindet zwei Netzwerke auf der Verbindungsschicht zu einem großen logischen Netzwerk. Eine Protokoll- und Adressenkonvertierung wird daher nicht vorgenommen.
Abb. C.3.1: Das Icon der ISDN-AppleTalk-Brücke auf dem Desktop
Mit Einschränkungen kann die Brücke auch verwendet werden, um von ISDN-AppleTalk aus auf weitere Geräte, wie z.B. Fileserver, in LocalTalk-Netzen zuzugreifen. Bei der hier implementierten Brücke handelt es sich nicht um eine vollständige AppleTalk-Brücke, die das Zonen- und Interzonen-Konzept unterstützt. Die Brücke stellt lediglich eine einfache Verbindung zwischen einem ISDN-AppleTalk-Netzwerk und einem AppleBus[9] auf der Link-Ebene her und ermöglicht den Aufbau einer Verbindung nur aus ISDN-AppleTalk[10].
C.3.1 Netzkonfiguration
Der primäre Zweck der ISDN-AppleTalk-Brücke ist die Anbindung eines AppleTalk-Druckers über einen AppleBus. Daher befindet sich im Normalfall auf der AppleTalk-Seite der Brücke lediglich ein Knoten (Abb. C.3.2). Auf der ISDN-AppleTalk-Seite kann eine Vielzahl von Geräten über die Brücke auf diesen Knoten (Drucker) zugreifen. Eine Transaktion wird stets vom ISDN-AppleTalk-Knoten gestartet. Die Brücke ist nicht in der Lage selbständig Verbindungen aufzubauen.
Abb. C.3.2: Versuchsanordnung zur Entwicklung
Da mehrere Ports gleichzeitig bedient werden müssen und eine hohe Gesamtübertragungsleistung benötigt wird, ist normalerweise für eine Brücke eine leistungsfähige Hardware, die Schnittstellen unabhängig vom Prozessor bedienen kann, erforderlich. Die hier beschriebene Druckerbrücke besteht nur aus Software und benutzt die beiden Ports eines Macintosh. Über Port A ist das ISDN-AppleTalk angebunden, am Port B befindet sich das normale AppleTalk (Abb. C.3.2). Um den Implementierungsaufwand gering zu halten, benutzt die Brücke zur Entgegennahme und zum Senden von AppleTalk-Paketen das normale ALAP. Am Port A werden die Pakete über Prozeduren ähnlich den Sende- und Empfangsprozeduren des ISDNLAP behandelt. Die Verwendung des eingebauten ALAP erübrigt zwar das Implementieren von Sende- und Empfangsroutinen auf der AppleTalk-Seite, bereitet jedoch Schwierigkeiten bei der Interruptbehandlung.
C.3.2 Adressierung in der ISDN-AppleTalk-Brücke
Die Adressierung in der Brücke muß so ausgelegt sein, daß der Klient die Brücke nach Möglichkeit nicht wahrnimmt und der Eindruck entsteht, daß direkt mit dem Drucker verhandelt wird. Eine Brücke soll sich bei der Benutzung des Netzwerkes neutral verhalten. Der Zugriff über eine Brücke darf keine Minderung der Übertragungsleistung bewirken. Das ist relativ unkompliziert, solange sich auf beiden Seiten der Brücke dieselbe Art des Netzwerkes befindet (Local Bridge). Aufwendiger wird die Implementierung, wenn es sich um grundverschiedene Netzwerke handelt. Dann wird die Konvertierung von Paketen und Netzwerkadressen erforderlich.
Bei der Übertragung eines Datenpaketes von ISDN-AppleTalk nach AppleTalk muß den Knoten auf der AppleTalk-Seite suggeriert werden, daß sie direkt von der Brücke und nicht von einer Station im ISDN-AppleTalk angesprochen werden. Das wird realisiert, indem die Node ID des anrufenden ISDN-AppleTalk-Knotens am Port B (AppleTalk) der Brücke gesetzt wird. Dabei genügt es nicht die Node ID nur im Parameter RAM zu setzen. Sie muß zusätzlich direkt in das Write-Kontrollregister 6 des Port B im SCC geschrieben werden. Außerdem müssen die Node IDs der AppleTalk-Zone (des Druckers) auch im ISDN-AppleTalk eindeutig sein. Zur Zeit wird die Eindeutigkeit der Node ID noch nicht automatisch gewährleistet, da die Brücke nur den Verbindungsaufbau durch Knoten im ISDN-AppleTalk erlaubt. Durch Eintragen des Druckers in die Listen des NameServers kann die Eindeutigkeit aber manuell sichergestellt werden. Datenpakete von einem AppleTalk-Knoten an einen Knoten im ISDN-AppleTalk werden von der Brücke unverändert weitergegeben.
C.3.3 Entgegennahme und Weiterleitung von Paketen
Neben der Adreßbehandlung hat die Brücke folgende Aufgaben der Paketbehandlung:
v Alle Datenpakete mit LAP-Typ 1 (kurze DDP-Pakete), die vom Klienten über Port A erhalten werden, gibt die Brücke über Port B an den Drucker weiter und umgekehrt.
v Alle Kontrollpakete aus beiden Netzen (ENQ, ACK, RTS, CTS) werden aus dem Datenstrom extrahiert und behandelt.
Bei der Weiterleitung von Paketen in der Brücke treten durch die unterschiedlichen Übertragungsgeschwindigkeiten beider Netze Komplikationen auf. Wie diese vermieden werden können, beschreiben die folgenden Abschnitte:
C.3.3.1 Behandlung von AppleTalk-Paketen
Während für die Paketübertragung in der Brücke auf der ISDN-Seite eigene Prozeduren verwendet werden, findet auf der AppleTalk-Seite über den AppleTalk Manager das AppleTalk Link Access Protocol Verwendung. Da beim Öffnen des .MPP der LAP-Typ 1 (kurze DDP-Pakete) bereits vom statischen Protocol Handler des DDP verwendet wird, muß dieser zuerst mit LAPCloseProtocol geschlossen werden. Auf der Seite von AppleTalk öffnet der Brückenprozess anschließend über den AppleTalk Manager einen Protocol Handler, um DDP-Pakete aus dem AppleTalk-Netz abzufangen, zu filtern und die Datenpakete vom LAP-Typ 1 an die ISDN-AppleTalk-Seite weiterzugeben.
Erreicht ein AppleTalk-Datenpaket über den Port B die Brücke, so wird es vom ALAP entgegengenommen und nach kurzer Bearbeitungszeit ∆C über die ISDNLAP-Prozedur TransmitFrame an den Knoten im ISDN-AppleTalk weitergegeben. Dabei dauert das Senden eines Paketes mit 64 kbit/s ungefähr viermal solange, wie das Empfangen. Ist dabei der Abstand ∆P zwischen nacheinander ankommenden AppleTalk-Paketen kürzer als die Summe aus Bearbeitungszeit in der Brücke ∆C und Übertragungszeit im ISDN-AppleTalk, so gehen ankommende Pakete verloren, wenn während der Übertragung eines Paketes mit TransmitFrame die Interrupts gesperrt sind (vgl. Abb. C.3.3). Verlorene Pakete werden beim Drucken zwar durch das Transport-Protokoll (ATP) wiederholt, verursachen aber durch das Abwarten von Timeouts im Sekundenbereich eine erhebliche Verlangsamung der Übertragung.
Abb. C.3.3: Paketverlust ohne Pufferung
Ein Verlust von Datenpaketen in der Brücke kann verhindert werden, indem ankommende Pakete gepuffert und nacheinander weitergeleitet werden. Dabei sind Receive-Interrupts zugelassen, so daß ankommende AppleTalk-Pakete empfangen werden können. Dadurch wird zwar das Senden eines Paketes gestört, ein Underrun des Transmitters kann jedoch leicht festgestellt und somit das Senden des gepufferten Paketes wiederholt werden (Abb. C.3.4). Erst wenn das Paket erfolgreich gesendet wurde, wird der Puffer freigegeben. Bei der Pufferung ist von Vorteil, daß das ATP maximal 8 Response-Pakete pro Request sendet. Ein Puffer, der 10 Pakete aufnehmen kann, reicht somit aus, um eine Sequenz hintereinander ankommender Pakete aufzunehmen.
Abb. C.3.4: Paketbehandlung bei Pufferung
Realisiert wird die Pufferung, indem in einem Feld der Platz für zehn ABRecords angelegt wird, die jeweils einen Zeiger auf ein Puffer enthalten. Durch Aufsetzen von asynchronen LAPRead-Calls in einer Queue werden die Puffer nacheinander vom ALAP beschrieben. Wurde ein Paket erfolgreich übertragen, so kann ein neuer LAPRead-Call mit dem freiwerdenden Puffer aufgesetzt werden.
C.3.3.2 Die Flußkontrolle bei der Übertragung von ISDNLAP-Paketen
Im Gegensatz zur Übertragung von Paketen von AppleTalk nach ISDN-AppleTalk hat eine Pufferung der Pakete bei der Übertragung in Gegenrichtung keinen Erfolg, da hier zum Senden die LAPWrite-Prozedur des Standard-AppleTalk verwendet wird. Diese sperrt bei der Übertragung eines Paketes alle Interrupts, so daß es nicht möglich ist beim Senden Pakete von der ISDN-AppleTalk-Seite zu empfangen. Pakete, die während dem Senden ankommen, gehen daher verloren und müssen wiederholt werden.
Abb. C.3.5: Flußkontrolle durch den ENQ/ACK-Handshake
Der Verlust von Paketen kann nur verhindert werden, indem eine Flußkontrolle implementiert wird. Dazu kann der Handshake dienen, der für das Testen der Leitung vor der Übertragung eines Paketes im ISDNLAP vorgesehen ist. Während ein Paket von der Brücke durch LAPWrite übertragen wird, sind die Interrupts des SCC gesperrt. Dadurch gehen ankommende ENQ-Pakete, die vor der Übertragung eines Datenpaketes zum Testen der Leitung und Prüfen der Node ID vom ISDN-AppleTalk-Knoten übertragen werden, für die Dauer des Interrupt verloren und es wird kein ACK-Paket erwidert. Erst wenn der Interrupt beendet, d.h. das vorangegangene Datenpaket übertragen ist, erhält der Knoten ein ACK-Paket und das nächste Datenpaket wird an die Brücke übertragen (Abb. C.3.5).
Der Programmieraufwand für diese Druckerbrücke war durch die Verwendung von bestehenden Programmteilen und der Standard-AppleTalk-Prozeduren relativ gering. Die augenblickliche Implementierung ist keine Brücke im Sinne von AppleTalk. Sie trennt das Netzwerk nicht in Zonen auf und ermöglicht noch keine automatische Adressierung. Dennoch können nicht nur Drucker, sondern in beschränktem Umfang auch andere Geräte in einem AppleTalk-Netzwerk über ISDN-Kanäle erreicht werden.