From: brianb@wc.novell.com (Brian Bulkowski)
Subject: Re: Appletalk I'Writer / Lost TRel
Organization: Novell Inc.
Date: Thu, 23 Jul 1992 18:16:40 GMT

Hi Doug and other ATP wonderers,
First, the receiver of an XO transaction does the following things -
1) Receives an XO request, creates a record of it (TCB)
2) Sends the replies
3) Keeps the replies in a buffer, (Transaction Control Block, or TCB) 
   waiting for a rerequested request;
4) Throws away the TCB when either
   a) it received a release, or
   b) the release timer goes off.

The time of the release timer is set in the TRel bits which are set
in the request. The common, default value of these bits is 30 seconds.
The possible values are 30sec, 1min, 2min, 4min, 8min.

So far so good, in an ideal world a dropped TRel just means a little
extra memory consumption while we wait for the buffers to be freed.
However, AppleTalk is an OS service and we don't want OS services
to consume unbounded amounts of memory. Likewise, we might not want
to go through the memory allocator for every transaction. (This starts
getting speculative here, I've never seen the Apple client code.)
So, the Mac preallocates a few TCBs - either 2 per session or 2 per mac,
I'm not sure, research suggests 2 per session, but I've mostly researched
ASP not PAP - and if those get stuck due to lost releases, you're SOL 
until that timer goes off. You keep dropping incoming requests until
you free up one of your TCBs.

Now, in modern days, we know that there are better ways to do things.
First is to create a system-wide pool that is multiple TCBs wide so that
usage spikes in one session don't hang that session. Second is to allocate
like heck because system memory is cheaper then Network performance.

But let's get back to a point - Doug said that the Laserwriter wasn't
sending the release. I've seen the various Laserwriters do lots of
strange things, but I've never seen them just plain not send releases.
More likely the packet was dropped somehow between the laserwriter and
the mac. Check Thy Cables. Check Thy Routers. In the absence of a better
Mac client, there's not much else we can do.

Hope this helps,
BrianB

In article <Jul.23.11.32.41.1992.6917@pilot.njin.net>, hedges@pilot.njin.net (Douglas Hedges) writes:
> 
> I was assigned to task of finding out why print jobs to
> our A'talk I'Writers would aperiodically stop in the middle
> of printing whereupon the workstation would exhibit a dialog
> box with the error message "Unable to maintain connection to
> the I'Writer (or something close to that).
> 
> After capturing some sessions and examining the packets
> it appears that in all cases it was the failure of
> the I'Writer printers to send a TRel packet releasing
> the transaction.  Instead the printer simply requested the 
> next data packet in sequence as identified by both the TID number
> and the PAP sequence number.  This continued for about 30 seconds
> (according to the time stamps) with the printer requesting
> the next data packet and the workstation, which hadn't a
> clue at that point, just sending status requests (which are of
> no use apparently in this case).  After 30 seconds, the workstation
> gave up and returned the dialog box with the error message
> about connecting to the printer.
> 
> As an experiment I tried capturing the I'Writer printers
> w/the Apple Print Server and damned if it didn't happen again
> due to a lost TRel, but this time the Print Server 
> failed to send it! I was using LocalPeek in all cases to
> capture the traffic; in none of those instances that failed
> was the TRel clobbered, it just didn't get sent.
> 
> Now I was under the impression from Inside A'talk (p 9-6?) that,
> in the event of a lost TRel, for whatever reason, the responder 
> was to remove the unacknowledged request from its list of
> requests and ... do what, I don't know.  (Inside Appletalk
> is vague at this point).  It seems reasonable that if the
> printer or spooler is requesting the next data packet in 
> sequence that would be implicit acknowledgement of having
> received the previous one in the event of a lost TRel.  
> 
> I'm not an A'talk guru and if any of the above seems hazy 
> it probably is but I'm quite clear that it was the
> absent TRel that triggered the sequence of events in all
> cases of failure.
> 
> Ideas from the cognoscenti would be most appreciated as
> to why the workstation end doesn't handle this more
> robustly.
> 
> 
Newsgroups: comp.protocols.appletalk