🚀 go-pugleaf

In article <dietrich-3007961857400001@imkeaa.medinn.med.uni-muenchen.de>,
dietrich@medinn.med.uni-muenchen.de (Johannes W. Dietrich) wrote:

> In article <krebs-3007961441480001@lake.gm.ufz.de>, krebs@water.gm.ufz.de
> (Daniel Krebs) wrote:
> 
> >> Auf Grund des 
> >> Protokoll-overhead nimmt man hier grundsaetzlich kein Appletalk.
> >
> >Das stimmt so nicht, wenn auch AppleTalk in WANs seltener seltener
> >anzutreffen ist. 
> 
> Interessant! AppleTalk produziert also keinen erh�hten Overhead? Gibt es
> dazu genauere Informationen?

AppleTalk hat in zwei Bereichen einen groesseren Overhead als TCP/IP:

Die Pakete sind kleiner, die beteiligten Rechner muessen daher fuer
dieselbe Datenmenge mehr Pakete verarbeiten. Bei WAN Verbindungen kommt
auch noch die relativ kleine Windowgroesse (8 Pakete) zum tragen, da
machen sich die WAN Latenzen ziemlich bemerkbar. Hier macht sich bemerkbar
das AppleTalk fuer ein 230 Kbit LocalTalk Netzwerk in Bus Topologie
designed wurde, groessere Paketlaengen und und groessere Windowgroessen
wuerden das recht langsame Netz zu lange fuer eine Transaktion belegen.
Leider wurde beim Design der Paketheader die Breite der einzelenen Felder
auch sehr klein gehalten um den Protokolloverhead zu minimieren. So kann
man auf schnelleren Netzen wie Ethernet oder FDDI keine laengeren Pakete
verwenden, weil das Paketlaengenfeld zu wenig Bits hat. Genauso hat die
AppleTalk Socket Nummer (entsprechend TCP/IP Port Nummer) nur 8 Bits,
somit kann man auf einem Rechner nur 254 (0 und 255 sind reserviert)
Sockets gleichzeitig offen haben.

Desweiteren produzieren die administrativen Funktionen (Naming und
Routing) mehr Pakete als in vergleichbaren TCP/IP Netzen. Die
Namingservices benutzen keine Caches und fragen direkt via Multicasting
nach Services. Das erzeugt bei WAN Verbindungen mehr Verkehr als
gewuenscht. Bei LAN Verbindungen wiederum hat es den Effekt des von Apple
bekannten Plug and Play (Networking bei einem Mac konfigurieren? Einfach
in den Stecker stecken und es tut).

Die Routing Services benutzen einen einfachen Broadcast Mechanismus um die
Routingtabellen alle 10 Sekunden zu verbreiten. Bei einem Backbone Netz
mit vielen Verbindungen zu kleineren Abteilungsnetzen kann der Verkehr
durch die Routing Broadcasts ziemlich hoch werden. Fuer WAN Verbindungen
gibt es da Abhilfe in dem statt dem einfachen RTMP Routing Protokolls das
effizientere AURP verwendet wird (das leider auch wesentlich komplizierter
ist).

Als Zusammenfassung:

AppleTalk ist ein Protokoll das fuer kleine bis mittlere Netze gedacht
ist. Alle Funktionen sind auf Plug und Play getrimmt, es ist somit
minimale Adminstration notwendig. Fuer ein globales WAN sollte man auf
Tunnel ueber TCP/IP zurueckgreifen moeglichst mit AURP um den Routing
Overhead zu minimieren.
______________________________________________________________________________
Jens-Uwe Mager                  jum@anubis.han.de
30177 Hannover                  jum@helios.de
Brahmsstr. 3                    Tel.: +49 511 660238