Path: utzoo!attcan!uunet!lll-winken!ames!pasteur!ucbvax!CS.CMU.EDU!Ravinder.Chandhok From: Ravinder.Chandhok@CS.CMU.EDU (Rob Chandhok) Newsgroups: comp.protocols.appletalk Subject: Re: Appletalk Bridge/Routing Inefficiency? Message-ID: <11090.607116692@GNOME.CS.CMU.EDU> Date: 28 Mar 89 19:31:32 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 27 Bob Morgan makes a good point about AppleTalk and dynamic router discovery. But the problem that Glenn pointed out is that once a route is discovered, it is silly (and I think unwise) to throw all your traffic from router to router. I agree, routers should be the smart things, and the 128K mac (which nobody has anymore) should be able to blindly go bouncing back and forth between N routers everytime it gets an RTMP packet. But in my case, I have on the order of 3 connections going at a time. I think a scheme not unlike ARP caches could be used to at least lower the massive fluctuations on the network (we all seem to understand aging cache entries, right?). If I have two routers, why burden each of them with *all* the traffic half the time? Isn't it smarter to (in the usual case) give each router half the traffic *all* the time? It seems to me that would be a more stable network. Having AppleTalk autoconfigure would also be more acceptable if you *could* give your driver some hints about the reality of the situation. That way, the default behavior would be to act like things are now, but you could say, modify the retransmit interval in AppleShare with the control panel (hint,hint). Bob's point about people time being more expensive than machine time should not be ignored. But in my case, my people are losing time due to deficiencies in the implementation. I could care less how hard the kbox has to work, the electricity costs about the same. Rob