-->"Eric" == Eric L Strobel <fyzycyst_at_home.com> writes:
Eric> After thinking more on this, though, there were two things
Eric> that I wondered about. First, just how big is this broadcast
Eric> that each AppleTalk device sends?
appletalk is a family of protocols, best documented by the "Inside
Appletalk" book, 2nd edition.
i don't know it too well, but there are a couple of places where
appletalk uses broadcast:
the first is in assigning a node address, where each machine just
picks a random number and asks if anything else is using it (a
broadcast). if something else is, it responds, and the process
repeats. as your zone gets full (i have a vague recollection of 256
machines in a zone?) this can take a lot of broadcasts.
another place is in the NBP -- the Name Binding Protocol -- which is
what the Chooser is using to find stuff. i forget exactly how this
works, but on large, multi-zone networks there's *always* someone
looking for a printer or fileserver or NCU or something, and so
there's a constant flood of broadcast traffic
Eric> Second, I'm not clear on how OTHER protocols are less of a
Eric> burden on bandwidth.
most other protocols (in most cases, this means IP and IPX ;-) are
built on the assumption that there exists an infrastructure maintained
by IT staff, and from that assumption are happy to rely on centralised
services.
for example, the IP DNS (not quite, but partially equivalent to NBP),
is a central service. each machine in the network must be configured
with a list of DNS server addresses.
and IP addresses themselves must be statically allocated, or
automatically handed out by a (centrally administered) DHCP server.
similarly for NFS (Network File System) which is roughly equivalent to
AppleShare. NFS client machines must be configured with the names of
their file servers.
this difference in mindset leads to protocols that scale more easily,
since that was a focus and the culture of those who designed them.
the Apple-designed protocols had a culture and focus on ease of use,
and deliberatly avoided any need for central administration or
authority.
the end result is that appletalk is easy to use for small groups with
no administration, and IP is better for larger groups with central
administration. both protocol suites have attempted to address the
issues targetted by the other, with varying success.
in fact, right now, the IETF zeroconf working group is in the process
of designing protocols to allow automatic allocation of IP addresses,
without the need for a DHCP server, using exactly the same principle
as AppleTalk does!
d
-- This is the Newtontalk mailinglist - http://www.newtontalk.net To unsubscribe or manage: visit the above link or mailto:newtontalk-request_at_newtontalk.net?Subject=unsubscribe
This archive was generated by hypermail 2.1.2 : Sat Dec 01 2001 - 20:02:26 EST