Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!gatech!dscatl!nanovx!matt
From: matt@nanovx.UUCP (Matt Brandt)
Newsgroups: comp.protocols.appletalk
Subject: the comming appletalk crisis
Keywords: bruhaha...
Message-ID: <514@nanovx.UUCP>
Date: 19 Feb 89 02:26:03 GMT
Organization: Boylan Enterprises, Ltd.  Norcross, GA
Lines: 23

I think the problems (other than the node limit) are overstated. Be reasonable.
On a large internet you might have a hundred or so bridges. The broadcasts
made by bridges to each other aren't really all that big a burdon (100
packets every ten seconds?) The node address aquisition isn't as bad as it
is made out to be either. Typically an appletalk station remembers it's last
address so that when it boots it tries that one first. You end up with a
pretty static set of node ID's after a very short while (the first time
all of the stations are active at once). From then on you just have a little
extra fault tolerance in that if the address happens to be aquired by a new
node you don't get a catastrophic failure when you try to bring up your node.
I think this is much better than the standard ethernet practice of having
the node number statically assigned.

The node limit is being addressed by allowing multiple LOGICAL appletalk
networks to co-exist on the same PHISICAL ethernet. This ups the node limit
to 65526 * 253. No real bridging is needed to communicate to a seperate
logical net. The station just notices that it is on the same wire and sends
the packet directly.

AppleTalk is generally much better thought out than most other protocols. The
only problem is that it was thought out as a small nework solution. Thats
what you get when you try to solve a problem (large networks) with the wrong
solution (AppleTalk). I think it does a pretty good job considering...