Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!kwe From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) Newsgroups: comp.protocols.appletalk Subject: Re: Appletalk Bridge/Routing Inefficiency? Message-ID: <29040@bu-cs.BU.EDU> Date: 29 Mar 89 17:54:18 GMT References: <11090.607116692@GNOME.CS.CMU.EDU> <334@taniwha.UUCP> Reply-To: kwe@buit13.bu.edu (Kent England) Followup-To: comp.protocols.appletalk Organization: Boston U. Information Technology Lines: 44 In article <334@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes: > >A few possibilities come to mind for workstations: > > 1) maintain an RTMP cache just like a router (you don't need to > keep a ZIP table if you still have the routers generate the NBP > lookups), this is not easy code to write and the tables can end > up using large amounts on memory on some of those giant nets > > 2) Whenever you receive a packet from another net remember what > the source net number and the LAP node number were, put them in > the cache, use the RTMP packets from that LAP address to keep them > valid (to validate the bridge lap address and to validate that > it's still the fastest way to get to it [in case of the config > changes]). Use the cache entries on transmission, if one isn't > present then fall back to the old method (the reply will fill a > cache entry) [maybe you don't put NBP response packets in the cache] > > 3) Just watch the RTMP packets and remember the one that is closest > to the most nets, that way you turn your 50% more towards 70% etc > (unless you really are right in the middle of things), or the one > that is closest to the most nets that you recently sent packets > to etc etc > >Well there's a start, and we didn't touch the protocol, personally I >like #2 falling back to #3, any other suggestions? > > I would point out that the conventional wisdom in the TCP/IP community is that, for a variety of reasons, workstations (or non-routers) should not snoop on or participate in router protocols, like RTMP. Of course, the TCP/IP community is still grappling with a router discovery protocol and dealing with multi-homed (multi-interface) hosts. I would think that there might be a clean way to ascertain the router to use during the process of name lookup. I think there should also be an independent router announcement protocol for implementations that want to keep a list of active routers for the purpose of selecting a default if the name lookup protocol is insufficient in all cases. Have to give some careful thought to direct versus thru-router name lookup, etc, but that's all part of the issue of dynamic router and internet topology discovery and what part of that process belongs in the "host"s.