🚀 go-pugleaf

lukas@phoenix.tp1.ruhr-uni-bochum.de (Lukas Wunner) writes:

>dietrich@medinn.med.uni-muenchen.de (Johannes W. Dietrich) writes:
>>>> 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?

>Also m.W. nach produziert Appletalk Overhead in rauhen Mengen; wie war
>das nochmal, jedes Byte muss acknowledged werden?

Das waren die Transputer-Links :-). Appletalk (insbesondere wenn
TCP/IP die Alternative ist) wird doch ganz normal auf dem Ethernet
gefahren, und das Protokoll der untersten Ebene ist das
selbe. Inwieweit die jeweiligen Protokolle (so viele gibt es bei
Appletalk ja nicht, mir faellte nur file-sharing und remote-printing
ein) groesseren oder geringeren Overhead haben, als die jeweiligne
TCP/IP Gegenstuecke, weiss ich nicht.

>IMHO skaliert Appletalk
>eher maessig, weshalb es fuer groessere Netze nur mit sehr starker
>Einschraenkung zu gebrauchen ist.

Der Hauptunterschied liegt doch in der Nutzung. Der Mac hat keine
Datei, in der z.B. die Hosts gespeichert sind, ebenso fehlt so etwas
wie DNS. Stattdessen wird die jeweilige Information bei Bedarf von den
beteiligten Hosts zusammengetragen. Das verursacht natuerlich Traffic
auf dem Netz, dafuer sind die Informationen immer brandaktuell (oder
niemals unvollstaendig und veraltet). Wenn der Benutzer einen
Fileserver ansprechen will, dann erhaelt er auch nur die Rechner zur
Auswahl, die File-Service anbieten und zwar jetzt in diesem
Augenblick. Ist der Server ausgeschaltet, dann taucht er auch nicht
auf. Allein von dieser Funktionalitaet sind die TCP/IP Dienste
meilenweit entfernt.

Ausserdem muss man Appletalk noch zu gute halten, dass es weniger
Einfluss auf Rechner mit anderen Protokollen auf dem selben Netz hat,
als TCP/IP. TCP/IP geht schweigend davon aus, dass alle
angeschlossenen Systeme wenigstens auch TCP/IP fahren. Deshalb werden
alle TCP/IP Broadcasts (sowohl die IP als auch die ARP Broadcasts) als
Ethernet-broadcasts versendet. Damit schlagen diese Pakete auch auf
allen Rechner ein, die z.B. XNS, SNA, IPX, DECnet, QNXnet oder auch
Ethertalk fahren und erzeugen dort CPU-Last. Ethertalk hingegen
benutzt nur Ethertalk-multicasts, so das die angeschlossenen Rechner
ihr Ethernetinterface entsprechend konfigurieren koennen, je nach dem,
ob diese Pakete benoetigt werden, oder nicht.

Insofern produziert TCP/IP einen groesseren Overhead als Ethertalk
(und zwar bei Netzwerkteilnehmern, die das jeweilige Protokoll nicht
benutzen).

73, Mario
--
Mario Klebsch, DG1AM, M.Klebsch@tu-bs.de		+49 531 / 391 - 7457
Institut fuer Robotik und Prozessinformatik der TU Braunschweig
Hamburger Strasse 267, 38114 Braunschweig, Germany