🚀 go-pugleaf

In article <4tvqke$f62@sun168.rz.ruhr-uni-bochum.de>,
lukas@tp1.ruhr-uni-bochum.de wrote:

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

ADSP ist ein Protokoll fuer einen bidirektionalen Bytestrom, es gibt noch
ein getrenntest Sessionprotokoll ASP das fuer File Services verwendet
wird. Wie auch bei TCP fuehrt ADSP alle moeglichen Sicherungen durch,
damit auch wirklich jedes Byte ankommt.

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

Das ist so nicht der Fall, die Absicherungsmechanismen von AppleTalk sind
nicht besser oder schlechter als die anderer Protokolle. Das wuerde ich
mal in das Reich der Maerchen verweisen.

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

Also AppleTalk hat _sehr_ wenig mit TCP/IP zu tun, wenn man mal von ADSP
absieht, was erst sehr spaet entstanden ist. Wenn ich mir AppleTalk so
anschaue, dann sehe ich da eher parallelen zu XEROX XNS. Aus dem ganzen
Sack von Protokollen die bei der AppleTalk Protokollfamilie verwendet
werden gibt es nur _ein_ Protokoll mit Aehnlichkeit zu TCP/IP, naemlich
ADSP (aehnlich TCP). ADSP wird allerdings von den Basisdiensten des MacOS
kaum verwendet (mir faellt da gerade nur Programm Linking und QD GX
PrinterShare ein). ADSP wird allerdings von vielen Applikationen
verwendet. Die Basisdienste wie Filesharing und Printing benutzen
transaktionsorientierte Protokolle (ASP und PAP mit der Basis ATP).
Transaktionsorientierte Protokolle gibt es in der Form bei TCP/IP gar
nicht (TTCP ist etwas sehr anderes!), das stammt eher aus der XNS Familie.

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

NBP verwendet keinerlei Cache und sendet staendig Queries wenn die Auswahl
offen ist. Die Auswahl erkennt allerdings wenn sie nur offen rumsteht und
sendet die Queries immer langsamer. Daher kann man ja einen Mac ins Netz
stecken und es tut auf Anhieb.

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

Sehe ich eher wie die erste Poster, denn bei TCP/IP ist ein erheblicher
Konfigurationsaufwand vonnoeten, man schaue sich nur mal die DNS RR Files
an. Erst in allerjuengster Zeit versucht die TCP/IP Gemeinde das ein wenig
zu vereinfachen, zum Beispiel mit DHCP. Allerdings gruselt es mich wie man
diese DHCP Server konfigurieren muss.

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

AppleTalk verwendet in der Tat keine Broadcasts und muss trotzdem nicht an
jeden Rechner ein Paket verschicken, denn es wird statt Broadcast
Multicast verwendet (auch fuer AARP). Multicasting ist eine Art von
spezialisiertem Broadcast der normalerweise nicht empfangen wird, sondern
erst im Ethernet Chip speziell angeschaltet werden muss. Multicasts werden
daher nur von Rechnern mit Interesse daran empfangen. Dieses ist uebrigens
mit IP-Multicasting auch bei TCP/IP moeglich. 

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

Da TCP/IP normalerweise so gut wie keine Broadcasts erzeugt, ist das in
der Tat ein wenig stark.

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

Ich habe die Artikel irgendwie in einer sehr merkwuerdigen Reihenfolge
erhalten, daher meine Replies ein wenig aus dem Kontext.
______________________________________________________________________________
Jens-Uwe Mager                  jum@anubis.han.de
30177 Hannover                  jum@helios.de
Brahmsstr. 3                    Tel.: +49 511 660238