(11. Juni 2004 — tk)

AppleTalk im Überblick

Unter AppleTalk versteht man heute einen ganzen Zoo von Netzwerkprotokollen, die fast 20 Jahre lang die Basis für die Vernetzung von Macs stellten aber seit ein paar Jahren zugunsten TCP/IP-basierter Protokolle von Apple zunehmend auf das Abstellgleis geschoben werden. Dank inzwischen verfügbarer Erweiterungen wie Rendezvous oder SLP, die die sprichwörtliche Idiotensicherheit von AppleTalk auch für TCP/IP verfügbar machen, ist dieser Schritt jedoch verschmerzbar.

Als Apple 1985 die unter dem Namen »Cambridge Ring« von Acorn und der University of Cambridge entwickelte Technologie »auslieh« und unter dem Namen AppleTalk vorstellte, stand der Begriff noch für sowohl Protokolle als auch Verkabelung/Topologie (ringförmiger Bus, Geschwindigkeit 230 KBit/sek brutto). Erst als Apple weitere Medientypen wie Ethernet oder Tokenring unterstützte, wurde AppleTalk zum Oberbegriff der Protokollfamilie umfunktioniert und die ursprüngliche Verkabelungsform LocalTalk getauft. Hinzu gesellten sich nun noch EtherTalk, FDDITalk, TokenTalk und IRTalk.

Vorrangiges AppleTalk-Designziel war die Befähigung der Geräte zur Selbstadministration. Ein frisch ans Netz angeschlossenes Device sucht sich selbständig eine freie AppleTalk-Adresse im passenden »Netrange« und registriert sich mit Name und anbietenden Diensten — und das, ohne DHCP- oder DNS-Server pflegen zu müssen. Anders als beispielsweise NetBEUI, das ähnliche Fähigkeiten nur innerhalb kleiner, nicht gerouteter Netze bereitstellt, sind die AppleTalk-Mechanismen auch in riesigen, bisweilen Kontinente überspannenden, gerouteten Installationen verfügbar.

Bei der Implementierung der höheren Protokolle war ebenfalls der Nutzen für die Anwender oberste Prämisse. PAP, das »Printer Access Protocol«, beispielsweise zeichnet sich durch konsequente Bidirektionalität und »8 Bit«-Fähigkeit aus. Ersteres beschert dem Anwender Komfort bei Konfiguration und Drucken (Benachrichtigung bezüglich Drucker-Features, Druckfortschritt oder Problemen wie Papierstau), letzteres keine Probleme mit binär kodierten Dokumenten aus der »digitalen Druckvorstufe«.

Den Vorteilen wie Benutzerfreundlichkeit und echtes »Plug and Play« stehen auch handfeste Nachteile gegenüber: Die zur Selbstadministration nötige »Geschwätzigkeit« von AppleTalk-Geräten und -Routern fordert ihren Tribut in Form eines permanenten »Grundrauschen« im Netz und die durch LocalTalk historisch bedingte Paketgröße von gerade mal 576 Byte stellt heutzutage einen äußerst ineffizienten Anachronismus dar. Ein Ethernet-Frame, der ein AppleTalk-Paket transportiert, enthält nur ein Drittel »Nutzlast«, was AppleTalk als Transportprotokoll zu Zeiten von Gbit-Ethernet witzlos macht: Deutlich geringerer Durchsatz bei höherer Systemlast, da mehr Frames/Pakete für die selbe Menge Nutzdaten verarbeitet werden müssen.

Mit der Einführung von TCP als weiteres Transportprotokoll für AFP vor ca. 7 Jahren hat Apple dem Rechnung getragen — dankenswerterweise wieder mit dem Anwender im Hinterkopf: Verstehen sich beide Seiten auf AFP over TCP, so kann der Erstkontakt auch via AppleTalk erfolgen — umgeschaltet wird dann automatisch im Hintergrund auf das effizientere TCP/IP.

Es ist daher aus Komfortgründen meist ratsam, AppleTalk zu benutzen, auch wenn man weder AFP over AppleTalk noch PAP benutzen möchte. Das oftmals vorgetragene Gegenargument, die simple Aktivierung einiger AppleTalk-Gerätschaften würde den Netzwerkdurchsatz allgemein einbrechen lassen, basiert auf Unwissenheit. Die paar AARP-, NBP-, ZIP- oder RTMP-Pakete, die für die Bereitstellung der AppleTalk-Komfortfeatures nötig sind, gehen völlig im Grundrauschen anderer Protokolle unter.

Copyright © Thomas Kaiser, 2008 (erstellt 11. Juni 2004 — tk)

Dieser Beitrag kann durch jedermann gemäß den Bestimmungen der Lizenz für die freie Nutzung unveränderter Inhalte genutzt werden. Die Lizenzbedingungen können unter http://www.uvm.nrw.de/opencontent abgerufen oder bei der Geschäftsstelle des Kompetenznetzwerkes Universitätsverbund MultiMedia NRW, Universitätsstraße 11, D-58097 Hagen, schriftlich angefordert werden.