🚀 go-pugleaf

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

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

<FLAME>
Transputer basierten auf der Idee, Kommunikationshardware und Computer
auf einen Chip zu integrieren und damit die Basis fuer grosse lose
gekoppelte Multiprozessorsysteme zu schaffen. Nun war die Chipflaeche
schon immer endlich und so mussten sowohl bei der
Kommunikationshardware und auch bei dem Computer Kompromisse
eingegangen werden, die letztendlich diese Geraete feur allgemeine
Aufgaben unbrauchbar gemacht habven :-(.
</FLAME>

Die Kommunikation war denkbar einfach. Sie erfolgt mit 10MBit/s
(wahlweise auch 5 oder 20). Dabei werden die Daten fast genau so wie
bei einem UART uebertragen. Einziger Unterschied: Es gibt zwei
verschiedene sorten Frames, die Daten-Frames sind 11 Bit lang, und die
Acklowledge Frames nur 2 Bit. Das Daten-Frame beinhaltet ein
Start-Bit(1), eine Kennung (1 fuer Datenframe), 8 Datenbits und ein
Stopbit(0). Das Acklowledge Frame hat nur ein Start-Bit (1) und eine
Kennung (0=Ack). Bei der Kommunikaton muss jedes einzelne Datenframe
(mit nur einem Byte Nutzdaten) bestaetigt werden.

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

Nur, dass IP keine Port-Nummern kennt. Der bessere Vergleich waere der
mit UDP.

> darueber dann ADSP, wohl ein TCP-Verschnitt uswusf.

Du meinst ATP. ATP garantiert jedoch im Gegensatz zu TCP, dass die
Messagegrenzen erhalten bleiben. Auserdem basiert TCP auf IP, waerend
ATP auf ddp basiert (OK, Du hast DDP ja als IP Ersatz betrachtet).

Ich denke, die Aehnlichkeit liegt eher in der Natur der Sache. Beide
Netzwerke benutzen ein verbindungsloses Transportmedium und arbeiten
Paketorientiert. Da hat man nicht mehr sehr viele Freiheiten, es
grossartig anders zu machen und hinterher noch ein brauchbares Produkt
zu haben. :-)

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

Ich denke, da besteht schon ein gewisser Unterschied. Bei Appletalk
werden nur die Nummern, nicht aber die Hostnamen dynamisch
vergeben. Bei IP hingegen existiert eine starre Kopplung zwischen
IP-Nummer und Host-Namen, insbesondere bei der langen Lebensdauer von
DNS Eintraegen.

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

Irgendwo schon, aber irgendwo auch nicht. Ich wuerde das NBP eher mit
dem Portmapper vergleichen. Dort melden sich die Applikationen beim
Startup an, und danach wird ihr Dienst geservt. DNS hingegen arbeitet
statisch. Die DNS Eintrage werden in einer Datei gespeichert und
werden geservt, unabhaenig davon, ob der jeweilige Rechner da ist,
oder nicht, und ebenfalls unabhaengig davon, ob der Rechner den
entsprechenden Dienst auch anbietet.

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

DNS und ARP benutzen beide einen Cache, aber DNS benutzt keine
Broadasts. DNS weiss, welchen Server es fragen muss. Genau deshalb
muss man es konfigurieren. Man kann das ueberhaupt nur machen, weil
der DNS Service zentral aufgebaut ist, und nicht jeder Rechner "seinen
Teil" dazu beitragen muss.

Ausserdem gibt es beim Mac eigentlich keine Hostname Lookups. Der Mac
praesentiert einen Chooser, der alle Rechner anzeigt, die den
gewuenschen Dienst anbieten. Diese werden natuerlich mittels Appletalk
Broadcast im Netz ermittelt. Wenn der Benutzer hiervon einen
auswaehlt, dann hat er schon die Nummer des Rechners. Damit kann die
Applikation dann loslegen. Weitere Lookups sind nicht noetig.

AARP und ARP sollten eigentlich keinen Unterschied machen.

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

Was hat das miteinander zu tun? Zugegeben ist Routing eine der
Staerken von IP, es jedoch als Ersatz fuer die oben aufgefuerhte
Funktionalitaet zu benennen, kann ich nicht ganz nachvollziehen. Hier
will uebrigens Niemand ein dem Internet vergleichbares
Appletalk-Netzwerk aufbauen. Ich denke, es ist jedem klar, dass das
nicht geht.

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

Per Multicast. Es gibt eine Multicast Addresse fuer alle Zonen
(9:0:7:ff:ff:ff) und dann noch 253 Multicast Addressen
(9:0:7:0:0:0-fc) fuer die einzelnen Zonen. Die Addrese errechnen sich
aus dem Namen der Zone. Ein Mac muss also auf zwei Multicast Addressen
lauchsn, um alle Broadcasts fuer ihn zu bekommen.

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

Es ist nur ein Paket, aber da es ein Multicast Paket ist, wird es von
allen anderen Rechnern schon von der Ethernet-Hardware ignoriert.

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

Ich sehe schon eine andere Moeglichkeit. Man koennte z.B. eine
Multicast Addresse fuer alle TCP/IP Broadcasts festlegen und diese
benutzen. Die Ethernet-Broadcasts sind eben an alle Rechner eines
Netzes, egal welches Protokoll sie fahren. Bei ARP Requests weiss man
aber schon vorher, dass sie nur von TCP/IP Systmen ueberhaupt
beantwortet werden koennen.

>Des weiteren hat doch m.W. nach Appletalk auch ein AARP (Apple-ARP)
>implementiert, wie wird das Problem da geloest?

Ebenso weis man, dass AARP Requests nur von Appletalk Systemen
beantwortet werden koennen. Wenn mann sogar schon die Zone des
Zielrechners kennt, kann man den Zone-Broadcast (Multicast-Addresse
9:0:7:0:0:0-fc) benutzen.

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

Ich stehe immer noch dazu und ich hoffe, Dich jetzt etwas davon
ueberzeugt zu haben.

73, Mario

P.S. Das alles gilt fuer Ethertalk Phase II.
--
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