🚀 go-pugleaf

mkl@rob.cs.tu-bs.de (Mario Klebsch) writes:
>>Also m.W. nach produziert Appletalk Overhead in rauhen Mengen; wie war
>>das nochmal, jedes Byte muss acknowledged werden?
>Das waren die Transputer-Links :-).

Hae? Kannst Du da drueber mal ein paar detailliertere Worte verlieren?

> 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.

Klar, die Transportsicherungs-Algorithmen werden natuerlich auf ner hoeheren
Ebene gefahren, z.B. in diesem Session-Protokoll (ADSP?). Allerdings bin
ich auch kein Appletalk-Spezialst und mein Wissen diesbzgl. basiert mehr
auf Gelesenem und Gehoertem. Vielleicht kann jemand mit Programmiererfahrung
im Bereich Appletalk mal was dazu sagen?

Man hoert und liest immer nur, dass Appletalk exzessive Absicherungs-
mechanismen (gegen schlechte Leitungen, weniger gegen boese Buben)
durchfuehrt. Urspruenglich wurde/wird ja das ganze ueber Klingeldraht
(aka Localtalk) gefahren, und dem Hoerensagen nach koennte man genausogut
die Macs an ein Heizungsrohr anschliessen und darueber dann Appletalk
fahren. Diese Geruechte, gepaart mit meinem Eindruck, dass beim MacOS
die Betonung wohl mehr auf der Usability liegt und Performance nur ne
ganz niedrige Prioritaet hat, bewog mich zu obiger Aussage. ;-)

>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.

Wie gesagt, in den Details kenn ich mich auch nicht aus, aber mein grober
Eindruck bei Appletalk ist, dass es sich da um eine waschechte Kopie von
TCP/IP handelt. Ganz offensichtlich haben sich Jobs & Co seinerzeit TCP/IP
angesehen, das ganze kompletto abgekupfert, ein paar Features rausgeschmissen
die ihnen nicht gefallen haben und ein paar rein, die Ihnen fehlten. Da hat
man z.B. auf unterster Ebene DDP, was ja wohl mehr oder weniger bis aufs Haar
IP gleicht, darueber dann ADSP, wohl ein TCP-Verschnitt uswusf. Die zu-
saetzlichen Features sind z.B. die automatische Nummernvergabe oder die
genannten exzessiven Absicherungsmassnahmen. Man kann sich zweifelsohne
trefflich darueber streiten, ob diese Features sinnvoll sind. Meine per-
soenliche Meinung ist: versuche bloss nicht, allzuviel Pseudo-Intelligenz
in den Rechner zu stecken, irgendwann fallen diese Algorithmen heftig auf
die Nase. Bei TCP/IP stehen derartige Funktionalitaeten mit z.B. DHCP
auch zur Verfuegung, allerdings sind sie eine Option und muessen nicht
verwendet werden.

>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.

Ist dem wirklich so? Ich hatte bisher den Eindruck, dass das Appletalk-
Pendant zu DNS einfach das NBP-Protokoll ist. Meine Vermutung waere, dass
hier aehnlich wie bei DNS oder ARP Abfragen gebroadcastet und in einem
kleinen Cache zwischengespeichert werden. Das waere ja schon ein Hammer,
wenn bei jedem Lookup ein Query gebroadcastet werden muss...

>Das verursacht natuerlich Traffic
>auf dem Netz, dafuer sind die Informationen immer brandaktuell (oder
>niemals unvollstaendig und veraltet).

Na jut, da kann man sich drueber streiten.

>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.

Seh ich persoenlich anders, schau Dir mal die (dynamischen) Routingprotokolle
an, ist einfach goettlich.

>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.

Das moecht ich jetzt aber doch genauer wissen: wie verschickt Appletalk
denn dann aufm Ethernet seine Broadcasts? Schickt es an jeden angeschlossenen
Mac ein einzelnes Paket? Dann wuerde ich ehrlich gesagt nicht den Nutzen
erkennen, da wird ja bei einem mittelgrossen Netz von sagen wir mal 50-100
Rechnern das Netz total zugemuellt (50-100 Pakete statt einem einzigen).
Dann saehe ich meine Vermutung, dass Appletalk maessig bis saumaessig
skaliert, bestaetigt. Und wie laeuft das bei ARP? Ich sehe eigentlich
keine andere Moeglichkeit, ARP Requests rauszuschicken wenn nicht via
Broadcast. Die Zieladresse kennt man ja noch gar nicht, also wie dann?
Des weiteren hat doch m.W. nach Appletalk auch ein AARP (Apple-ARP)
implementiert, wie wird das Problem da geloest?

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

Also das ist IMHO ne kuehne Behauptung.

Ok, ich hoff ich hab nicht zuviel flamebait produziert... ;-)
In jedem Fall waere es schoen, wenn jemand mit etwas tieferen Appletalk-
Kenntnissen da mal etwas Licht ins Dunkel bringen koennte...

	Lukas.

--
                                       __|     \ /     |__                
Lukas Wunner               _ o   ___\o    \o    |    o/    o/___  o _     
Brain- & Software           /\  /)  |     ( \  /o\  / )     |  (\  /\     
44801 Bochum            ___|_\______-- Heute schon gelebt? --______/_|___ 
United Germany                    lukas@tp1.ruhr-uni-bochum.de