home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / appletal / 2877 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  2.4 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!mips!zaphod.mps.ohio-state.edu!uwm.edu!rutgers!dziuxsolim.rutgers.edu!pilot.njin.net!hedges
  2. From: hedges@pilot.njin.net (Douglas Hedges)
  3. Newsgroups: comp.protocols.appletalk
  4. Subject: Appletalk I'Writer / Lost TRel
  5. Message-ID: <Jul.23.11.32.41.1992.6917@pilot.njin.net>
  6. Date: 23 Jul 92 15:32:42 GMT
  7. Organization: Rutgers Univ., New Brunswick, N.J.
  8. Lines: 43
  9.  
  10. I was assigned to task of finding out why print jobs to
  11. our A'talk I'Writers would aperiodically stop in the middle
  12. of printing whereupon the workstation would exhibit a dialog
  13. box with the error message "Unable to maintain connection to
  14. the I'Writer (or something close to that).
  15.  
  16. After capturing some sessions and examining the packets
  17. it appears that in all cases it was the failure of
  18. the I'Writer printers to send a TRel packet releasing
  19. the transaction.  Instead the printer simply requested the 
  20. next data packet in sequence as identified by both the TID number
  21. and the PAP sequence number.  This continued for about 30 seconds
  22. (according to the time stamps) with the printer requesting
  23. the next data packet and the workstation, which hadn't a
  24. clue at that point, just sending status requests (which are of
  25. no use apparently in this case).  After 30 seconds, the workstation
  26. gave up and returned the dialog box with the error message
  27. about connecting to the printer.
  28.  
  29. As an experiment I tried capturing the I'Writer printers
  30. w/the Apple Print Server and damned if it didn't happen again
  31. due to a lost TRel, but this time the Print Server 
  32. failed to send it! I was using LocalPeek in all cases to
  33. capture the traffic; in none of those instances that failed
  34. was the TRel clobbered, it just didn't get sent.
  35.  
  36. Now I was under the impression from Inside A'talk (p 9-6?) that,
  37. in the event of a lost TRel, for whatever reason, the responder 
  38. was to remove the unacknowledged request from its list of
  39. requests and ... do what, I don't know.  (Inside Appletalk
  40. is vague at this point).  It seems reasonable that if the
  41. printer or spooler is requesting the next data packet in 
  42. sequence that would be implicit acknowledgement of having
  43. received the previous one in the event of a lost TRel.  
  44.  
  45. I'm not an A'talk guru and if any of the above seems hazy 
  46. it probably is but I'm quite clear that it was the
  47. absent TRel that triggered the sequence of events in all
  48. cases of failure.
  49.  
  50. Ideas from the cognoscenti would be most appreciated as
  51. to why the workstation end doesn't handle this more
  52. robustly.
  53.