Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!apple!andrews
From: andrews@Apple.COM (Richard Andrews)
Newsgroups: comp.protocols.appletalk
Subject: Re:  ATP Timeouts
Message-ID: <35919@apple.Apple.COM>
Date: 25 Oct 89 21:53:00 GMT
Reply-To: andrews@apple.com (Richard Andrews)
Organization: Apple Computer Inc, Cupertino, CA
Lines: 28


> What about when the TREL gets dropped? AppleShare (other
> AFP-compatibles as well) SHOULD KEEP GOING while they keep the packets
> stashed somewhere till the 30-second (CAP) TREL timer goes off. CAP
> just blocks - stonewalls till the 30 seconds is up. You see a
> 30-second hole in the universe. I don't know what AppleShare does, but
> it exhibits the same behaviour (with a 10-20 second hole). Maybe it
> runs out of memory for the buffers or something?
 
> Does anyone know what AppleShare is really doing? Does it work better
> on a fat Mac II with lots of memory?
                            ---------
I reluctantly admit to being one of the authors of AppleShare, but I haven't
worked on it for over a year, so I won't be able to answer lots of questions.
I wanted to at least address the question above.
 
For each session, AppleShare, through ASP, queues up two ATP GetRequests.
If the TREL gets lost on one of those, requests and responses will continue
to flow on the session via the other GetRequest.  If, while we're waiting
for the 30-second timer to go off on one of these, the other TREL is lost,
the session will hang until the first 30-second timer goes off.  That's
probably why you've seen a "10-20 second hole".  I suspect that CAP only
has one GetRequest per session, and that's why it blocks for a full 30
seconds each time a TREL is lost.
 
That's what AppleShare is really doing.  If you only lose one TREL at a time
you will probably not notice anything.  It shouldn't work any better on
a fat Mac II with lots of memory, since it has nothing to do with memory.