9. Serverzugang in ISDN-AppleTalk
In einem AppleTalk-Netzwerk befinden sich außer normalen Knoten (Node ID 1–127) auch sog. Server (Node ID 128–254). Zu diesen Servern zählen Fileserver, aber auch verschiedene Drucker. Wie der Zugang zu diesen Diensten in ISDN-AppleTalk gehandhabt wird, bescheibt das folgende Kapitel.
9.1 Remote Disk Access in ISDN-AppleTalk
Der wichtigste Transaktionsdienst in AppleTalk ist der Remote Disk Access über AppleShare. Die Adressierung und Paketübertragung beim Zugriff auf Fileserver unterscheidet sich im allgemeinen nicht vom Zugriff auf andere AppleTalk-Knoten. Dennoch gibt es einige Besonderheiten, die auf den ersten Blick nicht zu erkennen sind:
9.1.1 Adressierung beim Remote Disk Access
Bei der Installation registriert sich ein AFPServer mit seinem Namen auf dem AppleTalk-Netzwerk. Die LkUp-Pakete der Registrierung werden zum NameServer übertragenen und der Inhalt der Pakete wird im Names Directory erfaßt. Gleichzeitig hält der NameServer die Node ID und die zugehörige Rufnummer des Fileservers fest. Dadurch wird der Fileserver allen Knoten im ISDN-Netzwerk zugängig.
Sucht eine AppleShare-Workstation über das Auswahl-Deskaccessory nach einem AFPServer, so werden periodisch (im Abstand von ca. 2 Sekunden) LkUp-Pakete an den NameServer übertragen. Dieser liefert den Names Table-Eintrag des AFPServers. Über die Node ID und die Socket-Nummer kann nun auf den Fileserver zugegriffen werden. Die Rufnummer zur Node ID des AFPServers erhält die Workstation ebenso vom NameServer. Der AFPServer wird nun angewählt und die AFP-Sitzung wird eröffnet. Ist die Rufnummer eines Fileservers bekannt, so kann jedoch auch direkt über die Rufnummer, ohne eine Registrierung des AFPServers am NameServer, zugegriffen werden (vgl. Abb. 9.1.1).
Abb. 9.1.1: Ein AppleShare Fileserver in ISDN-AppleTalk
Bei der Registrierung eines AFPServers am NameServer muß beachtet werden, daß die LkUp-Pakete, die ein AFPServer bei der Installation im Netzwerk aussendet, die Socket-Adresse des Session Listening Socket (SLS) und nicht die des Session Service Socket (SSS) enthalten. Beim Name LookUp nach einem AFPServer muß aber ein Klient vom NameServer ein LkUpReply-Paket mit der Socket-Adresse des Session Service Socket im Fileserver erhalten. Die Socket-Adresse muß daher im NameServer noch modifiziert werden[1].
9.1.2 Monopolisierung des Servers beim Remote Disk Access
Greift nur eine Station auf den AFPServer zu, so treten keine Probleme beim Remote Disk Access auf. Anders jedoch, wenn mehrere Stationen gleichzeitig am Server arbeiten. Durch die Wartung einer AFPSession[2] über die Tickle-Transaktion des ASP und durch den Update-Mechanismus des AFPTranslators in der Workstation werden fortlaufend Pakete zwischen Server und Workstation ausgetauscht. Durch den ständigen Verkehr und die retardierende Verbindungssteuerung bricht unter Umständen eine Verbindung zum Fileserver nicht mehr ab, so daß es zur Monopolisierung des Servers und zur Blockierung des Zugriffs weiterer Stationen kommt.
Abhilfe können folgende Methoden schaffen:
v Durch das Leistungsmerkmal „Anklopfen“ kann der Fileserver erkennen, daß weitere Stationen zugreifen wollen. Somit besteht die Möglichkeit, die Zeit einer Verbindung zum Server zu begrenzen und unter den Stationen aufzuteilen. Leider ist dieses Leistungsmerkmal für X.21-Verbindungen nicht verfügbar[3].
v Eine dynamische Anpassung des Timeouts der Verbindungssteuerung in Abhängigkeit von der Dauer einer Verbindung kann die Gefahr einer Monopolisierung zwar verringern aber nicht beseitigen. Der Timeout darf dabei nicht zu kurz werden, da andernfalls eine Verbindung während einer Transaktion abbricht. Außerdem bewirkt eine Anpassung des Timeouts keine Reduzierung der notwendigen Zugriffe auf einen Server.
v Es bleibt die Möglichkeit, die Zeitkonstanten zwischen den Kontrollpaketen des ASP und des Translators so zu patchen, daß die Zeit zwischen den Paketen verlängert und dadurch der Verkehr reduziert wird. Das hat jedoch den Nachteil, daß dieser Patch bei jeder neuen Version erneut vorgenommen werden muß[4] und eine Beeinträchtigung der Funktionsfähigkeit des AppleShare nicht auszuschließen ist.
Um in ISDN-AppleTalk den Zugriff mehrerer Stationen auf einen Fileserver über AppleShare zu gewährleisten, muß die Socketadresse des AFPServers im NameServer modifiziert und der Austausch von Kontrollpaketen (Verkehr) zwischen Server und Klient reduziert werden.
9.2 Printer Access in ISDN-AppleTalk
Neben dem Remote Disk Access ist das Drucken ein weiterer wichtiger Dienst in einem lokalen Netzwerk. Welche Vorkehrungen zu treffen sind, um auch das Drucken über ISDN-AppleTalk zu ermöglichen, wird im folgenden erörtert.
9.2.1 Anpassungsmöglichkeiten eines Druckers
Während als Fileserver meist ein Rechner dient (dedicated server), bestehen Drucker aus vergleichsweise unflexibler Spezialhardware. Zur Anpassung eines Druckers bestehen daher folgende Möglichkeiten:
v Die zunächst naheliegendste Lösung ist, ähnlich wie in den normalen AppleTalk-Knoten, das Link Access Protocol auszutauschen. Dagegen sprechen aber einige schwerwiegende Gründe:
- In einem normalen Rechner kann das LAP ersetzt werden, da der .MPP-Treiber des AppleTalk und das Betriebssystem von Platte oder Diskette geladen werden. Ein Drucker jedoch enthält sowohl das System als auch AppleTalk im ROM[5]. Dadurch wird es unmöglich, Treiber in Druckern anzupassen, ohne das gesamte ROM zu ersetzen.
- Die Hardware und Systemsoftware des LaserWriters unterscheidet sich erheblich von der eines Macintosh-Rechners, so daß unter Umständen ein völlig neues LAP zu implementieren wäre. Außerdem ist die Frage nach der Einbindung nicht geklärt.
Abb. 9.2.1: Zugang zum Drucker über eine Brücke
v Es bleibt also nur die Möglichkeit, für den Zugang über ISDN-AppleTalk vor den eigentlichen Drucker eine Brücke zu schalten und den Drucker wie bisher über AppleTalk zu betreiben. Die Brücke nimmt über ISDN Datenpakete entgegen und leitet über den AppleBus[6] an den Drucker weiter und umgekehrt (Abb. 9.2.1).
+ Die Brücke kann als Applikation auf einem Macintosh implementiert werden.
+ Über eine Brücke können nicht nur Drucker angesprochen, sondern auch ISDN-AppleTalk- und AppleTalk-Zonen zu einem großen Netzwerk verbunden werden.
- Die Implementierung ist i.a. technisch sehr anspruchsvoll und erfordert einen hohen Programmieraufwand (vgl. Seagate in Abschnitt 5.4).
+ Für die Brücke wird ein zusätzlicher Rechner notwendig.
9.2.2 Brücken und Internets in AppleTalk
In einem lokalen Netz kommt schnell der Wunsch auf, auch andere lokale Netze, im Haus oder außerhalb, erreichen zu können. Um einen Verbund von Netzwerken über Brücken zu realisieren, sind in AppleTalk entsprechende Protokolle und Mechanismen vorgesehen. Da diese auch für die Konzeption unserer Druckeranbindung von Bedeutung sind, werden sie im folgenden kurz vorgestellt.
9.2.2.1 Brücken, Router und Gateways
Mehrere lokale AppleTalk-Netzwerke (LocalTalk) können über Brücken oder Router zu einem Netz-Verbund zusammengeschlossen werden. Brücken koppeln lokale Netzwerke auf der Verbindungsschicht zu einem großen logischen Netzwerk und besitzen keine Logik zur Weglenkung. Router hingegen schließen gleichartige Zonen auf der Netzwerkschicht zu einem Netz-Verbund (Internet) zusammen. Gateways verbinden Netzwerke mit verschiedenen Protokollen auf der Transportschicht oder darüber und nehmen eine Protokollkonvertierung vor. In der AppleTalk-Nomenklatur werden Router und Gateways ebenfalls als Brücken bezeichnet. Dabei sind grundsätzlich drei Arten von Brücken zu unterscheiden (vgl. auch Abb. 9.2.2):
Abb. 9.2.2: Verschiedene Arten von Brücken
Lokale
Brücken (Local Bridge):
Lokale Brücken verbinden AppleTalk-Segmente direkt miteinander. Dadurch werden Netzwerke möglich, die mehr als 32 Knoten besitzen. Eigentlich handelt es sich hier nicht um eine Brücke, sondern um einen Router.
Halb-Brücken
(Half Bridge):
Diese Art von Brücke verbindet zwei LocalTalk-Netzwerke über eine weite Entfernung miteinander. Dabei ist das Medium auf der einen Seite der Brücke ein AppleBus, auf der anderen Seite befindet sich ein beliebiges anderes Medium. Die beiden Halb-Brücken und die Verbindung dazwischen erscheinen wie eine einzige Brücke zwischen zwei LocalTalk-Zonen (vgl. Abb. 9.2.2).
Backbone-Brücken (Backbone Bridge):
Durch diese Brücken werden mehrere LocalTalk-Zonen über ein schnelles Rückgrad-Netzwerk miteinander verbunden. Als Backbone-Netzwerk kann hier zum Beispiel, wie in Abschnitt 5.4 erwähnt, ein Ethernet dienen, das über Gateways angebunden ist.
9.2.2.2 Das Modell einer AppleTalk-Brücke
Eine Brücke ist ein AppleTalk-Knoten, der mehrere Hardware-Ports besitzt (Abb. 9.2.3). Ein Port kann entweder an ein LocalTalk-Netz, an ein Backbone-Netz oder an eine Wählverbindung angeschlossen sein. Jedem dieser Ports ist ein Port Descriptor zugeordnet, der die Portnummer, die Node ID des Ports und die Netzwerknummer des Netzes am Port enthält. Bei einem Halb-Brücken-Port sind dabei sowohl die Node ID als auch die Netzwerknummer unbekannt, d.h. sie haben den Wert 0. Für jeden Port muß je nach Medium, auf das er zugreift, ein gesonderter LAP-Prozeß vorhanden sein.
Abb. 9.2.3: Das Modell einer AppleTalk-Brücke
Um in einfachen Brücken alle Ports bedienen zu können, wird eine Pufferung der Pakete oder eine Flußkontrolle notwendig. Oft bestehen die Ports aus Spezialhardware, welche das Senden und Empfangen übernimmt. In der Brücke ist ein Router, eine Routing Table und ein Routing Table Maintenance Protocol vorhanden. Der Router empfängt Pakete von einem Port und leitet sie anhand der Zieladresse und der Routing Table an einen anderen Port weiter.
9.2.2.3 Adressierung im Internet
Zur Weglenkung von Paketen werden Zusatzinformationen in langen DDP-Frames verwendet (vgl. Abb. 4.2.11). Für jedes Netzwerk im Internet gibt es eine eindeutige 16-Bit-Netzwerknummer (vgl. Abb. 9.2.4). Ein Node im Internet besitzt eine eindeutige Adresse:
Internet Node ID:= Network#:Node ID
Analog setzt sich die eindeutige Adresse eines Sockets im Internet zusammen:
Internet Socket Address:= Network#:Node ID:Socket#
Internet-Pakete werden in Brücken eventuell umgewandelt, wenn sie ihr Zielnetzwerk erreicht haben. So werden etwa aus BrRq-Paketen in den Brücken LkUp-Pakete. Zur Begrenzung der Lebenszeit eines Paketes, und um ein endloses Zirkulieren zu verhindern, besitzt jedes lange DDP-Paket einen Hop Count, welcher beim Durchlaufen einer Brücke dekrementiert wird.
Abb. 9.2.4: Ein Internet mit Brücke und Halbbrücke
9.2.2.4 Protokoll-Unterstützung für Internets
Das Verbinden von AppleTalk-Zonen durch Brücken zu einem Internet wird in AppleTalk durch Protokolle unterstützt[7]:
v Internets und Brücken werden vom DDP (Netzwerkschicht) durch lange DDP-Pakete unterstützt. Diese werden über einen speziellen Protocol Handler 2 geleitet und besitzen Zusatzinformationen über das Ursprungs- und Zielnetzwerk, welche für die Weglenkung in Brücken benötigt werden.
v Das NBP unterstützt das Internet-Konzept durch Zonennamen in Names Table-Einträgen. Durch die Aussendung von BrRq-Paketen durch das NBP können Geräte im Internet lokalisiert werden.
v Das RTMP verwaltet die Weglenkungstabellen in Brücken, die Auskunft über den Weg und die Entfernung zu den einzelnen Brücken im Internet geben.
v Das ZIP übernimmt die Zuordnung von Internet-Adressen zu Zonennamen und gibt Auskunft über vorhandene Brücken (vgl. auch Abb. 4.2.24).
9.2.3 Anbindung eines Druckers über eine Brücke
9.2.3.1 Anbindung auf der Netzwerkschicht
Netzwerke mit verschiedenen Übertragungsprotokollen und Adressierungsarten werden normalerweise durch Gateways verbunden. Über einen ISDN-AppleTalk-Gateway kann eine ISDN-AppleTalk- mit einer AppleTalk-Zone auf der Netzwerkschicht verbunden werden (vgl. Abb. 9.2.5). Dabei sind jedoch folgende Punkte zu beachten:
- Router, die Zonen auf der Netzwerkebene verbinden, müssen Pakete gleichzeitig an mehreren Ports entgegennehmen können. Für das Weiterleiten der Pakete betreiben sie ein aufwendiges Routing anhand von Weglenkungstabellen. Daher bestehen Brücken meist aus teurer Spezial-Hardware (vgl. Seagate in Abschnitt 5.4).
- Die Implementierung eines Gateways, der ISDN-AppleTalk- mit AppleTalk-Zonen verbindet, ist sehr aufwendig. Es muß nicht nur ein kompletter Routing-Algorithmus implementiert werden, sondern es ist auch notwendig, die Adressierung in ISDN-AppleTalk und den NameServer für das RTMP und das ZIP zu erweitern.
+ Die Software zum Bau eines AppleTalk-Gateways für EtherTalk ist kostenlos von der Stanford Universität zu beziehen[8]. Anhand dieses Quellcodes können das Routing von Paketen sowie die Aufgaben einer AppleTalk-Brücke studiert werden.
+ Nur ein ISDN-AppleTalk-Gateway gewährleistet die volle Integration und Funktionsfähigkeit einer ISDN-AppleTalk-Zone in einem AppleTalk-Internet.
Abb. 9.2.5: Prinzipieller Aufbau eines ISDN-AppleTalk-Gateways
Trotz der Vorteile für den Betrieb eines ISDN-AppleTalk-Netzwerkes ist der Implementierungsaufwand für einen ISDN-AppleTalk-Gateway, nur um einen Drucker an das ISDN-AppleTalk anzubinden, zu hoch. Längerfristig muß jedoch diese Lösung favorisiert werden.
9.2.3.2 Anbindung auf der Verbindungsschicht
Alternativ zu einer Anbindung auf der Netzwerkschicht besteht die Möglichkeit einer Verbindung der ISDN-AppleTalk- und der AppleTalk-Zone auf der Verbindungsschicht. Dadurch werden die beiden Zonen zu einem großen logischen Netzwerk verbunden. Für den Einsatz in ISDN-AppleTalk bestehen dabei folgende Vor- und Nachteile.
+ Diese Art der Anbindung ist mit einem vergleichsweise geringen Implementierungsaufwand verbunden.
+ Da keine Weglenkung stattfindet und nur zwei Ports zu bedienen sind, ist wenig Rechenleistung erforderlich, so daß ein Macintosh Plus als Brücke eingesetzt werden kann.
+ Der ISDN-AppleTalk-Port wird von den Routinen des ISDNLAP bedient. Um den AppleTalk-Port zu betreiben, kann das eingebaute AppleTalk Link Access Protocol verwendet werden (vgl. Abb. 9.2.5).
+ Eine Anbindung auf der Link-Ebene genügt für das Drucken.
- Die Brücke ist nicht voll funktionsfähig im Sinne des AppleTalk-Interzonen-Konzepts.
- Verbindungen können nur von seiten des ISDN-AppleTalk aufgebaut werden, da andernfalls das ISDN-AppleTalk zu sehr durch die Pakete der AppleTalk-Zone belastet würde. Da ein Druckvorgang immer von einem Knoten im ISDN-AppleTalk gestartet wird, ist ein aktiver Verbindungsaufbau durch die Brücke jedoch nicht erforderlich.
- Durch die Verbindung auf der Link-Ebene werden beide Zonen zu einem großen logischen Netzwerk vereint. Daher eignet sich eine Anbindung auf der Verbindungs-schicht nur dann, wenn gewährleistet ist, daß die Node IDs aller Stationen in beiden Zonen eindeutig sind, d.h. daß sich in der AppleTalk-Zone kein Gerät befindet, das dieselbe Node ID wie ein ISDN-AppleTalk-Knoten besitzt.
Die dynamische Node-Adressierung im
Netz-Verbund:
Eine Brücke auf der Verbindungsschicht verhält sich neutral. Datenpakete werden von der Brücke unverändert durchgereicht. Port A leitet alle Datenpakete über Port B an den Drucker weiter, Port B übergibt die empfangenen Pakete über Port A an das ISDN-AppleTalk. Die LAP-Kontrollpakete in beiden Zonen unterscheiden sich jedoch und können nicht ohne weiteres weitergereicht werden. Um dennoch die Eindeutigkeit von Node IDs in beiden Teilnetzen zu gewährleisten, sind verschiedene Methoden zur dynamischen Node-Adressierung über die Brücke denkbar:
v Knoten in der AppleTalk-Zone müssen sich genauso wie ISDN-AppleTalk-Knoten bei der dynamischen Node-Adressierung am NameServer anmelden. Um festzustellen, ob in der AppleTalk-Zone bereits ein Knoten mit der eigenen Node ID existiert, übertragen ISDN-AppleTalk-Knoten ihre ENQ-Pakete über die Brücke an die AppleTalk-Zone. Umgekehrt müssen alle AppleTalk-Knoten sich am NameServer anmelden und ihre Node IDs mit denen in NameServer abstimmen. Das ist aber nicht möglich, da dann zu viele Pakete gefiltert oder von der Brücke verteilt werden müßten. Ein Verbindungsaufbau seitens der Brücke ist also nicht sinnvoll.
v Ein Aufteilen der Node ID-Bereiche ist ebenso nicht möglich, da das ISDN-AppleTalk keinen Einfluß auf die Node-Adressierung in der AppleTalk-Zone hat.
v Besteht eine Zone, wie beim Anschluß eines Druckers, nur aus der Brücke und dem Drucker (AppleBus) und wurde die Node ID dieses Druckers manuell am NameServer registriert, so kann es zu keinen Problemen mit der Adressierung kommen.
Überzeugend lösen lassen sich diese Adressierungsprobleme jedoch nur mit einem ISDN-AppleTalk-Gateway.
Die
Registrierung von Gerätenamen:
Auf ein Gerät in einer AppleTalk-Zone wird entweder direkt über die Rufnummer der Brücke zugegriffen[9], oder aber das gesuchte Gerät ist am NameServer registriert. Das Eintragen am NameServer kann entweder von Hand geschehen oder die Brücke sieht einen Algorithmus vor, der bestimmte Geräte in der AppleTalk-Zone sucht und am NameServer mit Namen und Node ID unter der Rufnummer der Brücke registriert:
v Ein Drucker wird dem ISDN-AppleTalk bekannt, indem er manuell mit seiner Node ID und der Rufnummer der Brücke, sowie seinem Gerätenamen in die Listen des NameServers aufgenommen wird. Bei der Auswahl eines Druckers über den Chooser wird durch LkUp-Pakete der Drucker am NameServer gefunden. Über seine Node ID kann er unter der Nummer der Brücke angesprochen werden. Alle Pakete an den Drucker werden nun an die Druckerbrücke gerichtet.
v Alternativ zum manuellen Eintragen eines Druckers am NameServer ist denkbar, daß die Brücke alle in einer Resource angegebenen Geräte durch einen Name LookUp im AppleTalk-Netzwerk sammelt und diese am NameServer registriert. Damit können alle gefundenen Geräte von ISDN-AppleTalk aus erreicht werden. Über ENQ-Pakete an den NameServer wird die Nummer der Brücke unter verschieden Node IDs registriert. Laserdrucker besitzen in AppleTalk-Netzwerken dabei die NBP-Typenbezeichnung „LaserWriter“. Matrixdrucker sind als „ImageWriter“ ansprechbar.
Abb. 9.2.6: Der Brückenprozeß der ISDN-AppleTalk-Brücke
Für eine ISDN-AppleTalk-Brücke auf der Verbindungsschicht werden beide Ports des Macintosh benötigt. Port A ist mit dem ISDN-AppleTalk verbunden, Port B über einen AppleBus mit dem Drucker. Somit hat jeder Port getrennte Aufgaben zu erfüllen. Pakete werden vom einem Brückenprozeß zwischen den beiden Ports ausgetauscht (Abb. 9.2.6). Da für den AppleTalk-Port das eingebaute ALAP verwendet werden soll, ist es nicht möglich Steuer- und Kontrollpakete weiterzuleiten. Sie werden gesondert behandelt. Die Implementierung einer einfachen Brücke beschreibt Anhang C.3.
9.2.3.3 Remote Disk Access über die ISDN-AppleTalk-Brücke
Über die ISDN-AppleTalk-Brücke ist es prinzipiell auch möglich, ISDN-AppleTalk nicht nur über den AppleBus mit einem Drucker, sondern auch mit einem LocalTalk zu einer großen Zone zu verbinden (vgl. Abb. 9.2.7). Dadurch wird es ISDN-AppleTalk-Knoten ermöglicht auf Dienste im LocalTalk zuzugreifen. Umgekehrt ist das jedoch nicht möglich, da die Brücke eigentlich für den Zugriff auf einen AppleTalk-Drucker von seiten des ISDN-AppleTalk konzipiert wurde. Eine dynamische Node-Adressierung wird von der Brücke nicht unterstützt. Somit kann der Fall eintreten, daß in beiden Zonen jeweils ein Knoten mit derselben Node ID vorhanden ist. Beim Anbinden eines LocalTalk müssen daher alle Knoten am NameServer registriert werden. Danach dürfen im LocalTalk keine neuen Knoten mehr hinzu kommen.
Abb. 9.2.7: Die AppleTalk-ISDN-Brücke verbindet ISDN-AppleTalk mit AppleTalk
Da sich AppleShare-Fileserver passiv verhalten und eine Transaktion stets vom Klienten ausgeht, kann über die Brücke auch auf einen Fileserver in der angebundenen AppleTalk-Zone zugegriffen werden. Dem ISDN-AppleTalk-Knoten wird dieser Fileserver zugängig gemacht, indem er entweder am NameServer registriert wird oder der Knoten bei bekannter Rufnummer direkt auf die Brücke zugreift.
ISDN-AppleTalk ermöglicht nicht nur den Zugriff zu AppleShare-Fileservern über Wählverbindungen, sondern mithilfe einer einfachen Brücke auch das Drucken.