Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!ucbvax!JESSICA.STANFORD.EDU!morgan From: morgan@JESSICA.STANFORD.EDU Newsgroups: comp.protocols.appletalk Subject: Re: Appletalk Bridge/Routing Inefficiency? Message-ID: Date: 28 Mar 89 18:32:23 GMT References: <2224@aecom.YU.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 37 Glen: [ Glen Marianko comments that AppleTalk's dynamic router discovery method leads to inefficient routing. ] Let's not (once again) bash AppleTalk for not being something it wasn't intended to be, and let's not forget you don't get something for nothing. I'll bet you probably didn't notice anything unusual with this net performance-wise until you put your Lanalyzer on the Ethernet. Any large packet can be sent to the wrong Kbox and resent on the Ethernet in far less time than it takes to transmit it on the LocalTalk, so this "inefficiency" is trivial from the client Mac's point of view. Assuming your Ethernet isn't overloaded already, it's not really a problem there, either. An older Kbox may be a bottleneck, but then it wasn't designed to support high-performance file service, either. What you may have noticed is that when you set up this network you didn't have to configure *anything* having to do with router addresses, default routes, etc. The dynamic protocol that bothers you is what makes that possible. The philosophy is that the client station, which may be a 128K Mac, shouldn't have to know anything except the address of *some* router, not necessarily the "best" one. The router, being smarter, will worry about routing. If a router fails, the client will find out about another working one promptly, and use it. I consider the time I spend explaining to neophyte network administrators about default IP router addresses, and fixing misconfigured machines, to be the real "inefficiency". I hope AppleTalk 2 doesn't lose too much ease of use in its pursuit of performance. - RL "Bob" Morgan Networking Systems Stanford