home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / appletal / 2882 < prev    next >
Encoding:
Text File  |  1992-07-23  |  4.7 KB  |  101 lines
  1. Newsgroups: comp.protocols.appletalk
  2. Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!mips!newsun!brianb@wc.novell.com
  3. From: brianb@wc.novell.com (Brian Bulkowski)
  4. Subject: Re: Appletalk I'Writer / Lost TRel
  5. Message-ID: <1992Jul23.181640.16051@novell.com>
  6. Sender: usenet@novell.com (The Netnews Manager)
  7. Nntp-Posting-Host: 130.57.64.121
  8. Organization: Novell Inc.
  9. References: <Jul.23.11.32.41.1992.6917@pilot.njin.net>
  10. Date: Thu, 23 Jul 1992 18:16:40 GMT
  11. Lines: 88
  12.  
  13. Hi Doug and other ATP wonderers,
  14. First, the receiver of an XO transaction does the following things -
  15. 1) Receives an XO request, creates a record of it (TCB)
  16. 2) Sends the replies
  17. 3) Keeps the replies in a buffer, (Transaction Control Block, or TCB) 
  18.    waiting for a rerequested request;
  19. 4) Throws away the TCB when either
  20.    a) it received a release, or
  21.    b) the release timer goes off.
  22.  
  23. The time of the release timer is set in the TRel bits which are set
  24. in the request. The common, default value of these bits is 30 seconds.
  25. The possible values are 30sec, 1min, 2min, 4min, 8min.
  26.  
  27. So far so good, in an ideal world a dropped TRel just means a little
  28. extra memory consumption while we wait for the buffers to be freed.
  29. However, AppleTalk is an OS service and we don't want OS services
  30. to consume unbounded amounts of memory. Likewise, we might not want
  31. to go through the memory allocator for every transaction. (This starts
  32. getting speculative here, I've never seen the Apple client code.)
  33. So, the Mac preallocates a few TCBs - either 2 per session or 2 per mac,
  34. I'm not sure, research suggests 2 per session, but I've mostly researched
  35. ASP not PAP - and if those get stuck due to lost releases, you're SOL 
  36. until that timer goes off. You keep dropping incoming requests until
  37. you free up one of your TCBs.
  38.  
  39. Now, in modern days, we know that there are better ways to do things.
  40. First is to create a system-wide pool that is multiple TCBs wide so that
  41. usage spikes in one session don't hang that session. Second is to allocate
  42. like heck because system memory is cheaper then Network performance.
  43.  
  44. But let's get back to a point - Doug said that the Laserwriter wasn't
  45. sending the release. I've seen the various Laserwriters do lots of
  46. strange things, but I've never seen them just plain not send releases.
  47. More likely the packet was dropped somehow between the laserwriter and
  48. the mac. Check Thy Cables. Check Thy Routers. In the absence of a better
  49. Mac client, there's not much else we can do.
  50.  
  51. Hope this helps,
  52. BrianB
  53.  
  54. In article <Jul.23.11.32.41.1992.6917@pilot.njin.net>, hedges@pilot.njin.net (Douglas Hedges) writes:
  55. > 
  56. > I was assigned to task of finding out why print jobs to
  57. > our A'talk I'Writers would aperiodically stop in the middle
  58. > of printing whereupon the workstation would exhibit a dialog
  59. > box with the error message "Unable to maintain connection to
  60. > the I'Writer (or something close to that).
  61. > 
  62. > After capturing some sessions and examining the packets
  63. > it appears that in all cases it was the failure of
  64. > the I'Writer printers to send a TRel packet releasing
  65. > the transaction.  Instead the printer simply requested the 
  66. > next data packet in sequence as identified by both the TID number
  67. > and the PAP sequence number.  This continued for about 30 seconds
  68. > (according to the time stamps) with the printer requesting
  69. > the next data packet and the workstation, which hadn't a
  70. > clue at that point, just sending status requests (which are of
  71. > no use apparently in this case).  After 30 seconds, the workstation
  72. > gave up and returned the dialog box with the error message
  73. > about connecting to the printer.
  74. > 
  75. > As an experiment I tried capturing the I'Writer printers
  76. > w/the Apple Print Server and damned if it didn't happen again
  77. > due to a lost TRel, but this time the Print Server 
  78. > failed to send it! I was using LocalPeek in all cases to
  79. > capture the traffic; in none of those instances that failed
  80. > was the TRel clobbered, it just didn't get sent.
  81. > 
  82. > Now I was under the impression from Inside A'talk (p 9-6?) that,
  83. > in the event of a lost TRel, for whatever reason, the responder 
  84. > was to remove the unacknowledged request from its list of
  85. > requests and ... do what, I don't know.  (Inside Appletalk
  86. > is vague at this point).  It seems reasonable that if the
  87. > printer or spooler is requesting the next data packet in 
  88. > sequence that would be implicit acknowledgement of having
  89. > received the previous one in the event of a lost TRel.  
  90. > 
  91. > I'm not an A'talk guru and if any of the above seems hazy 
  92. > it probably is but I'm quite clear that it was the
  93. > absent TRel that triggered the sequence of events in all
  94. > cases of failure.
  95. > 
  96. > Ideas from the cognoscenti would be most appreciated as
  97. > to why the workstation end doesn't handle this more
  98. > robustly.
  99. > 
  100. > 
  101.