🚀 go-pugleaf

Johannes W. Dietrich (dietrich@medinn.med.uni-muenchen.de) wrote:
: Hallo Freunde,

: an unserer Klinik gibt es Plaene, AppleTalk nicht mehr zu unterstuetzen
: sondern kuenftig nur noch TCP/IP zu routen. Um diese unerwuenschte
: Entwicklung zu verhindern wollen wir (die Mac-Arbeitsgruppen) u. a. auf
: die groessere Sicherheit von AppleTalk hinweisen, und zwar hinsichtlich:

: - Datensicherheit (Abstuerze, Netzunterbrechungen etc.)

: - Datenschutz (Eindringen von Hackern...).

: Kann da jemand etwas substanzielles sagen? Hat jemand eigene Erfahrungen
: gemacht? Oder gibt es vielleicht sogar Literatur dazu?

: Freue mich auf jede Antwort!

Hallo Johannes,
das Ganze sieht mir nach unnoetiger Panikmache aus. Moeglicherweise geht
es hier nicht um die "Endloseung der Apfelbenuzter" sondern nur um eine
praktikable Loesung fuer die Verbindung im WAN-Bereich. Auf Grund des 
Protokoll-overhead nimmt man hier grundsaetzlich kein Appletalk. Das Verfahren
nennt man "tunneling". Die ADSP-Pakete von Appletalk werden somit in
TCP/IP-Pakete oder Novell IPX Pakete verpackt und in der Zielzone wieder
ausgepackt. Von dieser Protokollwandlung merkt der Benutzer nichts. Sofern
die Routerloesung dieses "tunneling" beherscht, besteht also kein Grund zur
Aufregung. Ich habe mal bei einer der fuehrenden Unternehmensberatungen
Deutschlands gearbeitet. Man konnte ueber "Auswahl" ohne Probleme
die Zonen der Niederlassungen in Berlin, Hamburg, Muenchen, Paris, Mailand, etc.
anwaehlen. In Wirklichkeit wurde die Verbindung ueber das Netware Loadable
Router-Module eines Novell-Netware-Servers aufgebaut.

Also bitte erst mal nachfragen, ob hier wirklich die Hinrichtung aller
Applebenutzer Gegenstand der Aktion ist

Mit besten Gruessen
Rainer Daeschler
 

In article <4tjb4c$7q1@newsserv.zdv.uni-tuebingen.de>,
rdae@miyako.zdv.uni-tuebingen.de (Rainer Daeschler) wrote:

>Das Verfahren
>nennt man "tunneling". Die ADSP-Pakete von Appletalk werden somit in
>TCP/IP-Pakete oder Novell IPX Pakete verpackt und in der Zielzone wieder
>ausgepackt. Von dieser Protokollwandlung merkt der Benutzer nichts. Sofern
>die Routerloesung dieses "tunneling" beherscht, besteht also kein Grund zur
>Aufregung. 

Das ist mir schon bekannt. Nur: Die Router koennen AppleTalk nicht tunneln.

Suche also weiterhin nach Information...

Vielen Dank!

J. W. D.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- Johannes W. Dietrich
--
-- Medizinische Klinik am Klinikum Innenstadt, University of Munich
-- Ziemssenstr. 1, D-80336 Munich, Germany
--
-- Phone: +49-89-5160-2281,    Fax: +49-89-5160-2341
-- AppleTalk-Kennung: "INN-Med:Dev220-Quadra 650 Dietrich"
-- eMail: INTERNET:"dietrich@medinn.med.uni-muenchen.de"
-- WWW: http://www.med.uni-muenchen.de/mki/instruct/instruct_home.html
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

In article <4tjb4c$7q1@newsserv.zdv.uni-tuebingen.de>,
rdae@miyako.zdv.uni-tuebingen.de (Rainer Daeschler) 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. 

> Das Verfahren
> nennt man "tunneling". Die ADSP-Pakete von Appletalk werden somit in
> TCP/IP-Pakete oder Novell IPX Pakete verpackt und in der Zielzone wieder
> ausgepackt.

Das w�re ziemlich unpraktikabel. Schlie�lich sind IPX und TCP/IP auch nur
LAN-Protokolle, die im WAN in X.25, HDLC, PPP etc. verpackt werden (Na
gut, wie das bei IPX ist wei� ich nicht.). Genauso kann man auch AppleTalk
in HDLC oder X.25 einpacken. Im B-WIN geht das im Augenblick aber noch
nicht, weshalb hier in der Tat AppleTalk getunnelt werden mu� :-(

> Also bitte erst mal nachfragen, ob hier wirklich die Hinrichtung aller
> Applebenutzer Gegenstand der Aktion ist

Nat�rlich wird es nicht so sein, schlie�lich k�nnen die Macs ja auch IP.
Aber was passiert z.B. mit den AppleShare Fileservern...
AppleTalk ist meines Erachtens bequemer f�r einen normalen Macuser, wenn
es auch langsamer ist. Wichtig ist es also, festzustellen, welche
Bandbreiten im gesamten Netz zur Verf�gung stehen und ob die vorhandenen
Router in der Lage sind, das AppleTalk-Protokoll auch im WAN zu routen. Je
gr��er der AppleTalk-Netzwerk-Verbund ist, desto mehr broadcast-Verkehr
hast du dann auch. Die kann man aber mit acess-lists auf den Routern ein
wenig eind�mmen.
Da AppleTalk kein offenes Protokoll ist, halte ich es im WAN auch f�r
sicherer. Dieser Vorteil ist aber dahin, wenn jemand Zugang zu einem
AppleTalk-f�higen Rechner im LAN hat, oder sich sogar mit einem Sniffer
ins Netz h�ngt.
Aber nat�rlich kann man neben AppleTalk auch IP routen. F�r die
Netzwerksicherheit gibt es schlie�lich Firewalls etc.
Ich w�rde mir erstmal ansehen, was f�r Anwendungen im Netz laufen, sollen
die AppleShare-Dienste auf NFS oder FTP umgestellt werden...
Vorerst;
Daniel

* Daniel Krebs
* UFZ Research Centre
* Heydeckstrasse 9
* 39104 Magdeburg
* Germany
* phone: +49 391 5681534 // +49 391 8507455
* fax:     +49 391 5681544 // +49 391 8507500

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?

Kannst Du mir da einen Feedback geben?

Johannes
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- Johannes W. Dietrich
--
-- Medizinische Klinik am Klinikum Innenstadt, University of Munich
-- Ziemssenstr. 1, D-80336 Munich, Germany
--
-- Phone: +49-89-5160-2281,    Fax: +49-89-5160-2341
-- AppleTalk-Kennung: "INN-Med:Dev220-Quadra 650 Dietrich"
-- eMail: INTERNET:"dietrich@medinn.med.uni-muenchen.de"
-- WWW: http://www.med.uni-muenchen.de/mki/instruct/instruct_home.html
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

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?
> 
> Kannst Du mir da einen Feedback geben?

Na klar :-)
Du hast mich nicht ganz richtig verstanden, ich hatte nur dementieren
wollen, da� AppleTalk in WANs grunds�tzlich nicht geroutet w�rde.
Wenn man AppleTalk durch IP oder IPX tunnelt, hat man nat�rlich einen
Protokolloverhead. Aber das ist ja wiegesagt nicht n�tig.
Was die Unterschiede zwischen IP und AppleTalk hinsichtlich Headergr��e
und Packetgr��e angeht, bin ich �berfragt, jedenfalls gibt es da
Unterschiede (AppleTalk-Packete sind, soweit ich mich erinnere, kleiner
(soso, also mehr header pro Byte)). Kennst Du das >Apple Handbuch
Datenkommunikation und Netzwerke< (Addison Wesley 1993)? Ist schon
ziemlich veraltet, aber der theoretische Hintergrund stimmt nat�rlich
noch.
W�rde mich interessieren, ob es inzwischen eine neuere Auflage gibt, die
auch OpenTransport behandelt...
Daniel

-- 
* Daniel Krebs                          
* UFZ-Centre for Environmental Research            
* e-mail: krebs@water.gm.ufz.de         
* voice: (0391) 5681534                
* fax: (0391) 5681544                                          

In article <krebs-3107961418590001@gmfmac2.gm.ufz.de>,
krebs@water.gm.ufz.de (Daniel Krebs) wrote:


>Das ist richtig, zumal sogar die Pa�w�rter im Klartext �bers Netz gehen.
>Aber um die Packete zu analysieren, mu�t Du erstmal ins Netz kommen.
>Daniel

Soweit ich weiss, schickt AppleTalk die Passwoerter verschluesselt ueber
das Netz, waehrend TCP/IP Klartext benutzt.

Johannes
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- Johannes W. Dietrich
--
-- Medizinische Klinik am Klinikum Innenstadt, University of Munich
-- Ziemssenstr. 1, D-80336 Munich, Germany
--
-- Phone: +49-89-5160-2281,    Fax: +49-89-5160-2341
-- AppleTalk-Kennung: "INN-Med:Dev220-Quadra 650 Dietrich"
-- eMail: INTERNET:"dietrich@medinn.med.uni-muenchen.de"
-- WWW: http://www.med.uni-muenchen.de/mki/instruct/instruct_home.html
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

In article <4tndtm$3en@ra.ibr.cs.tu-bs.de>, kalkan@ramz.ing.tu-bs.de (Ove
Kalkan) wrote:

> Wusste nicht das Apple-Talk auch Paketverschluesselung aehnlich Kherberos
> unter Unix unterstuetzt.
> Wenn sie unverschluesselt sind, sind alle Pakete gleich anfaellig fuer Hacker.
> Einfach einen Netzwerksniffer zwischen die Leitung klemmen und mithoeren.

Das ist richtig, zumal sogar die Pa�w�rter im Klartext �bers Netz gehen.
Aber um die Packete zu analysieren, mu�t Du erstmal ins Netz kommen.
Daniel

-- 
* Daniel Krebs                          
* UFZ-Centre for Environmental Research            
* e-mail: krebs@water.gm.ufz.de         
* voice: (0391) 5681534                
* fax: (0391) 5681544                                          

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

|> - Datenschutz (Eindringen von Hackern...).

Wusste nicht das Apple-Talk auch Paketverschluesselung aehnlich Kherberos
unter Unix unterstuetzt.
Wenn sie unverschluesselt sind, sind alle Pakete gleich anfaellig fuer Hacker.
Einfach einen Netzwerksniffer zwischen die Leitung klemmen und mithoeren.

Die geringe Verbreitung eines Protokolls ist kein Schnutz (schliesslich
gibt es sowas wie Inside Macintosh:Networking zu kaufen :-)).

MfG, O.Kalkan
--
Ove Kalkan - Symbiose
Rechenanlage des Mechanikzentrums der Technischen Universitaet Braunschweig
Tel: (0531) 391 7074
Email: kalkan@ramz.ing.tu-bs.de

In article <dietrich-3107961919270001@imkeaa.medinn.med.uni-muenchen.de>,
Johannes W. Dietrich <dietrich@medinn.med.uni-muenchen.de> wrote:
>Soweit ich weiss, schickt AppleTalk die Passwoerter verschluesselt ueber
>das Netz, waehrend TCP/IP Klartext benutzt.

Das Netzwerkprotokoll und die Frage, ob Passwoerter verschluesselt werden
haben doch nichts miteinander zu tun. Das haengt davon ab, was die
Programme machen, die darauf aufbauen, ganz unabhaengig vom Transportprotokoll.

- Wulf
-- 
 ____________________________________________________
| Wulf Hofbauer (w.hofbauer@physik.uni-stuttgart.de) |
| Universitaet Stuttgart  2. Physikalisches Institut |
| Pfaffenwaldring 57     70550 Stuttgart     Germany |

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

> >Das ist richtig, zumal sogar die Pa�w�rter im Klartext �bers Netz gehen.
> >Aber um die Packete zu analysieren, mu�t Du erstmal ins Netz kommen.
> >Daniel
> 
> Soweit ich weiss, schickt AppleTalk die Passwoerter verschluesselt ueber
> das Netz, waehrend TCP/IP Klartext benutzt.

Peinlich, peinlich, wieder mal Mist geschrieben...
Daniel

* Daniel Krebs
* UFZ Research Centre
* Heydeckstrasse 9
* 39104 Magdeburg
* Germany
* phone: +49 391 5681534 // +49 391 8507455
* fax:     +49 391 5681544 // +49 391 8507500

kalkan@ramz.ing.tu-bs.de (Ove Kalkan) writes:
>Wusste nicht das Apple-Talk auch Paketverschluesselung aehnlich Kherberos
>unter Unix unterstuetzt.

Von Haus aus zwar nicht, mit diversen Add-Ons aber offenbar schon. Im
netatalk Paket ist eine Authentifikationsfunktionalitaet fuer unterschiedliche
Mechanismen implementiert (u.a. Kerberos); ob sich dies auch von der
reinen Authentifikation auf die Verschluesselung von Datenverkehr in
Echtzeit ausweiten laesst, kann ich indes nicht sagen...

>Die geringe Verbreitung eines Protokolls ist kein Schnutz (schliesslich
>gibt es sowas wie Inside Macintosh:Networking zu kaufen :-)).

Das gesamte Buch kann man sich zudem von ftp.apple.com saugen. ;-)

	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            

Daniel Krebs <krebs@water.gm.ufz.de> wrote:

> 
> Das ist richtig, zumal sogar die Pa�w�rter im Klartext �bers Netz gehen.
> Aber um die Packete zu analysieren, mu�t Du erstmal ins Netz kommen.
> Daniel

Zum Beispiel mit "snoop". Ist auf jeder Sun drauf. Man kann auch gezielt
nach AppleTalk Packets suchen.

-- 
Arne Schirmacher                |  Pix Software GmbH
arne@stargate.gun.de            |  Windows NT / UNIX / Macintosh
                                |  software development and consulting
In der Ruhe liegt die Kraft.    |  Tel. +49 2163 953030, Fax 953031

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? IMHO skaliert Appletalk
eher maessig, weshalb es fuer groessere Netze nur mit sehr starker
Einschraenkung zu gebrauchen ist.
(please correct me if I'm wrong)

	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            

phy10412@rpool9.rus.uni-stuttgart.de (Wulf Hofbauer) writes:

>In article <dietrich-3107961919270001@imkeaa.medinn.med.uni-muenchen.de>,
>Johannes W. Dietrich <dietrich@medinn.med.uni-muenchen.de> wrote:
>>Soweit ich weiss, schickt AppleTalk die Passwoerter verschluesselt ueber
>>das Netz, waehrend TCP/IP Klartext benutzt.

>Das Netzwerkprotokoll und die Frage, ob Passwoerter verschluesselt werden
>haben doch nichts miteinander zu tun. Das haengt davon ab, was die
>Programme machen, die darauf aufbauen, ganz unabhaengig vom Transportprotokoll.

Nur dass du selten NFS Server findest, die Ethertalk sprechen und fast
ebenso selten Ethershare Server, die TCP/IP koennen. Da gibt es schon
einen Zusammenhang. Jedes Protokoll hat "seine" Programme.

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

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

In article <krebs-3007961441480001@lake.gm.ufz.de>, krebs@water.gm.ufz.de
(Daniel Krebs) wrote:

> Da AppleTalk kein offenes Protokoll ist, halte ich es im WAN auch f�r
> sicherer. Dieser Vorteil ist aber dahin, wenn jemand Zugang zu einem
> AppleTalk-f�higen Rechner im LAN hat, oder sich sogar mit einem Sniffer
> ins Netz h�ngt.

Aehem, das ist nicht so. AppleTalk mag nicht in RFC's dokumentiert sein,
aber es gibt ein Buch von Apple namens "Inside AppleTalk", das enthaelt
alle Einzelheiten die zu einer Implementation notwendig sind. Ich wuerde
deswegen sagen auch AppleTalk ist ein offenes Protokoll nennen.

AppleTalk _kann_ sicherer sein, weil fuer File Services ein recht
raffinierter Authentisierungs-Mechanismus verwendet wird, der keine
Kennwoerter ueber das Netz schickt. Ausserdem wird bei einem Logon nicht
nur der Client gegenueber dem Server authentisiert sondern auch der Server
gegeueber dem Client.
______________________________________________________________________________
Jens-Uwe Mager                  jum@anubis.han.de
30177 Hannover                  jum@helios.de
Brahmsstr. 3                    Tel.: +49 511 660238

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            

jum@anubis.han.de (Jens-Uwe Mager) writes:
>AppleTalk hat in zwei Bereichen einen groesseren Overhead als TCP/IP:
[...]

Tausend Dank fuer die kompetente Antwort!

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

Aha, offenbar RTMP==RIP.

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

Wie ist das mit den Protokollen auf hoeherer Ebene, z.B. AFP? Offenbar
ist hier ebenfalls der Overhead groesser, mglw. dank diverser exzessiver
Fehlerkorrektur-Verfahren?

>30177 Hannover                  jum@helios.de
				     ^^^^^^ Ah ja. :-)

Nochmals danke,
	Lukas.

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

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

> Wie ist das mit den Protokollen auf hoeherer Ebene, z.B. AFP? Offenbar
> ist hier ebenfalls der Overhead groesser, mglw. dank diverser exzessiver
> Fehlerkorrektur-Verfahren?

AppleTalk betreibt keine exzessiven Fehlerkorrektur Verfahren, in keinem
Protokoll. Es ist sogar eher weniger als bei TCP/IP, da die DDP Pruefsumme
optional ist und fast immer ausgeschaltet ist. Die einzigen wesentlichen
Overhead erzeugenden Eigenheiten sind die kleineren Pakete und die
relative kleine Window Groesse (alle 8 Pakete ein Ack).
______________________________________________________________________________
Jens-Uwe Mager                  jum@anubis.han.de
30177 Hannover                  jum@helios.de
Brahmsstr. 3                    Tel.: +49 511 660238

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

Lukas Wunner <lukas@phoenix.tp1.ruhr-uni-bochum.de> wrote:

> 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

Das bezweifle ich!

Das man beim Design eines Netzwerkprotokolls schichtenweise vorgeht
hatte sich bereits 1984 als vorteilhaft erwiesen. Meines Erachtens hat
man sich bei Apple damals mehr von ISO/OSI inspirieren lassen.

AppleTalk ist jedoch konzeptionell so weit von IP entfernt, dass man
sicherlich nicht von einer Kopie reden kann. Nach Deiner Argumentation
waere der ISO/OSI Ansatz (Schichten 1 bis 4) ebenfalls eine 'waschechte
Kopie von TCP/IP'. Dies entspricht sicherlich nicht ganz den Tatsachen.

Ciao
Sven

-- 
Sven Braun                  Sven.Braun@stud.uni-karlsruhe.de (preferred)
Am Kuenstlerhaus 37         ukr4@rz.uni-karlsruhe.de
76131 Karlsruhe             s_brauns@ira.uka.de
Germany                     Telefon 0721 386329

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

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

jum@anubis.han.de (Jens-Uwe Mager) writes:

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

Ich brauche hier nur mal einen "snoop -P broadcast" zu starten, dann
kann ich deutlich sehen, wie viele broadcast Packete hier
eintrudeln. Das sind so ca 2-4 pro Sekunde. Das nenne ich nicht "so
gut wie keine". Das meiste sind ARP Pakete, gefolgt von rwho
Broadcasts.

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

In article <mkl.839332371@dagobert.rob.cs.tu-bs.de.rob.cs.tu-bs.de>,
mkl@rob.cs.tu-bs.de (Mario Klebsch) wrote:

> Ich brauche hier nur mal einen "snoop -P broadcast" zu starten, dann
> kann ich deutlich sehen, wie viele broadcast Packete hier
> eintrudeln. Das sind so ca 2-4 pro Sekunde. Das nenne ich nicht "so
> gut wie keine". Das meiste sind ARP Pakete, gefolgt von rwho
> Broadcasts.

Wohl viele HP�s im Netz? Normalerweise sollte ein ARP Eintrag 20 Minuten
(arpt_killc) im Cache bleiben. Eine Ausnahme sind da meines Wissens die HP
Maschinen, die schicken wohl ARP Pakete oefters. Und rwho gibt es bei uns
ueberhaupt nicht, der ist noch nie angeschaltet gewesen. Da sehe ich eher
irgendwelche Multicasts von SGI Objektservern.
______________________________________________________________________________
Jens-Uwe Mager                  jum@anubis.han.de
30177 Hannover                  jum@helios.de
Brahmsstr. 3                    Tel.: +49 511 660238

In article <1996080915390420410@kithnos.ethz.ch>, awuertz@access.ch
(=?ISO-8859-1?Q?Andreas_W=FCrtz?=) wrote:

> Technisch hab ich nicht viel dazu zu sagen (waere ziemliches Glatteis
> fuer mich, wie offensichtlich auch fuer andere, die sich aber drauf
> wagen... :-)

Danke ;-)
 
> Aber hier ein kleiner Trost: FileMaker IST schon TCP/IP faehig und
> AppleShare soll's mit der naechsten Version werden.

FileMaker ist nicht nur IP- und IPX- f�hig, sondern gibt es auch f�r W95
(wie gesagt, kein Waschmittel), NT und demn�chst auch f�r Windoofs 3.11.
(Habe gestern bei Claris angerufen :-)
Was AppleShare angeht, danke f�r die gute Nachricht, das wu�te ich noch
nicht. Fragt sich nur, wann die n�chste Version kommt...
Daniel

-- 
* Daniel Krebs                          
* UFZ-Centre for Environmental Research            
* e-mail: krebs@water.gm.ufz.de         
* voice: (0391) 5681534                
* fax: (0391) 5681544                                          

Johannes W. Dietrich <dietrich@medinn.med.uni-muenchen.de> wrote:

> Kann da jemand etwas substanzielles sagen? Hat jemand eigene Erfahrungen
> gemacht? Oder gibt es vielleicht sogar Literatur dazu?

Technisch hab ich nicht viel dazu zu sagen (waere ziemliches Glatteis
fuer mich, wie offensichtlich auch fuer andere, die sich aber drauf
wagen... :-)

Aber hier ein kleiner Trost: FileMaker IST schon TCP/IP faehig und
AppleShare soll's mit der naechsten Version werden.

Abgesehen davon, dass also AppleTalk scheinbar wirklich ein bisschen
sicherer ist (weil Passwoerter nicht oder zumindest nicht im Klartext
hin- und hergeschickt werden), bedeutet die Umstellung auf TCP/IP nicht
das Ende der Konnektivitaet fuer Euch. Ausserdem: wer hindert Euch,
einen eigenen kleinen Mac-Router mit IP-Tunneling aufzubauen? Hab zwar
keine Detailkenntnisse, aber es sollte ohne grossen Aufwand moeglich
sein.

Wie die Amis so schoen sagen: nur meine 2-Pfennig (oder so :-))

&Tschuess
Andy

Daniel Krebs <krebs@water.gm.ufz.de> wrote:

> nicht. Fragt sich nur, wann die naechste Version kommt...

Wenn ich mich richtig erinnere, Ende des Jahres (_dieses_ Jahres :-))

-- 
****************************************  Andreas Wuertz
* The only person who got all his work *  Im Tiergarten 6a
* done by Friday was Robinson Cruesoe  *  CH-8055 Zuerich
****************************************  Switzerland

In article <19960811001934134006@spetses.ethz.ch>, awuertz@access.ch
(=?ISO-8859-1?Q?Andreas_W=FCrtz?=) wrote:

> Wenn ich mich richtig erinnere, Ende des Jahres (_dieses_ Jahres :-))

Na hoffentlich...
D.

-- 
* Daniel Krebs                          
* UFZ-Centre for Environmental Research            
* e-mail: krebs@water.gm.ufz.de         
* voice: (0391) 5681534                
* fax: (0391) 5681544                                          

Daniel Krebs (krebs@water.gm.ufz.de) wrote:

>> Was AppleShare angeht, danke f�r die gute Nachricht, das wu�te ich noch
>> nicht. Fragt sich nur, wann die n�chste Version kommt...

laut Apple (Cupertino) schon Ende diesen Jahres! Diverse bekannte
Internetprotokolle (TCP/IP, POP, FTP, HTTP,...) sollen sich dann wohl
im neu definierten AppleShare wiederfinden. Naja, MacOS 8 sollte ja 
auch schon mal Ende 1996 auf den Markt kommen ...  ;-)

So long,
Lars

--
Lars Wessels   Tullastrasse 72   76131 Karlsruhe   GERMANY
Phone/Fax: +49-721-623359      email: lars@nordsee.inka.de 
<http://www.inka.de/~nordsee/> PGP Key availble on request
PGP fgprt: 70 73 B0 F7 D6 F0 6A AF 3C 1F 20 05 C9 19 89 06