Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!uakari.primate.wisc.edu!ames!cincsac.arc.nasa.gov!medin
From: medin@cincsac.arc.nasa.gov (Milo S. Medin)
Newsgroups: comp.protocols.appletalk
Subject: Re: UDPTalk as a backbone
Message-ID: <31440@ames.arc.nasa.gov>
Date: 6 Sep 89 22:32:04 GMT
References: <1989Sep6.165747.23972@caen.engin.umich.edu> <1989Sep5.192546.15473@caen.engin.umich.edu> <31397@ames.arc.nasa.gov>
Sender: usenet@ames.arc.nasa.gov
Lines: 31

> FastPaths use to supply original routes aren't RTMP packets.  It happens
> that with 64 routes, the packet used to supply routes to FastPaths is full.
> You will have to send additional packets to the routers, except reception
> of a packet causes the FastPath to clear out its current routes and replace
> them.  Information the the source code would imply that there is a slightly
> different kind of packet you can send to supply additional routes, but
> atalkad never sends it and doesn't mention the format.  So although 64 is a
> constant in the code, it isn't an ARBITRARY constant, and making it larger
> gains you nothing.

Well, I think I said that you had to have a KIP capable of dealing with more
entries.  If you support frag/reassembly, you don't need to change anything
else.  You get bigger packets.  Granted, this method doesn't last 
forever, and the right thing to do is add incremental updates (you are
aging routes anyway), but frag is needed anyways inside the things.  We
don't have problems hacking code inside the box, though I can understand
why most sites wouldn't want to do it.  Then again, most large sites 
would have the support staff necessary to do it.  

> 
> Looking through the KIP source code seems to imply that KIP supports it, but
> I don't think its been tested too well.

You are right, we haven't hacked in frag reassembly yet, though that's
a fairly straightforward thing to do.  You could fix it by adding 
incremental updates, but that's trickier (in my opinion) than hacking
in reassembly.  I'd be happier if we never had to support that much 
Appletalk, but that's how it goes...

						Thanks,
						   Milo