home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / mac / programm / 20394 < prev    next >
Encoding:
Internet Message Format  |  1992-12-29  |  2.6 KB
  1. Path: sparky!uunet!uchdcc!camino.mic.cl!thomas
  2. From: thomas@camino.mic.cl (Thomas Fruin)
  3. Newsgroups: comp.sys.mac.programmer
  4. Subject: Re: DECnet packets via ARA getting truncated!?
  5. Organization: El Camino
  6. Message-ID: <0105013E.mcbl7x@camino.mic.cl>
  7. Reply-To: Thomas Fruin <thomas@camino.mic.cl>
  8. Distribution: world
  9. X-Mailer: uAccess - Macintosh Release: 1.5v4
  10. Lines: 55
  11. Date: Tue, 29 Dec 1992 18:55:27 CST
  12.  
  13.  
  14. In article <0105013E.m9gd41@camino.mic.cl> (comp.sys.mac.programmer), Thomas Fruin <thomas@camino.mic.cl> writes:
  15.  
  16. >My application receives DECnet packets which are always approximately
  17. >1024 bytes in size. My protocol specifies that if there is no more
  18. >data in a packet, it should be padded with spaces until the end.
  19.  
  20. >Now here's the weird problem: ONLY when I connect remotely, DECnet
  21. >packets get filled with spaces near the end, overwriting part of the
  22. >information in the packet. The size of the packet is perfect, except
  23. >that the information in it gets overwritten. This problem does not
  24. >occur if I connect locally using Ethernet.
  25.  
  26. I have some more data to add to the previous description of my problem
  27. with DECnet packets getting truncated:
  28.  
  29. The problem seems to be related to the encapsulation of DECnet
  30. in AppleTalk, because the problem appears both when using AppleTalk
  31. Remote Access and when using a Macintosh on LocalTalk. And the problem
  32. does not consist of truncation, but of receiving large DECnet packets
  33. as multiple small AppleTalk packets.
  34.  
  35. After some more debugging, I found out that sometimes my ~1K DECnet
  36. packets get delivered in two pieces. The first CMRead will sometimes
  37. return only 537 bytes (instead of 1066, which is the standard size
  38. of my packet). When that happens, the second packet is inevitably
  39. 529 bytes (making a total of 1066).
  40.  
  41. My theory is that most of the time the multiple AppleTalk packets
  42. get concatenated into full DECnet packets by my DECnet driver, but
  43. when the two pieces arrive too far apart in time, the driver goes
  44. ahead and gives me the first piece.
  45.  
  46. So my new questions are the following:
  47.  
  48. 1.- Can somebody confirm my theory of the encapsulation of DECnet
  49.     in AppleTalk, and how packets are delivered by the DECnet driver
  50.     in Pathworks?
  51.  
  52. 2.- How can I tell if a packet received by my call to CMRead is a
  53.     full or a partial packet? On examining the 'caps' resource in
  54.     the DECnet tool, I found out that it doesn't support end-of-message
  55.     flags, which I presume I should be using in this case.
  56.  
  57. Thanks and bedankt to the folks who sent me their suggestions and
  58. help!
  59.  
  60. -- Thomas Fruin
  61.  
  62.    GroupWare Ltda
  63.    Temuco Office
  64.    CHILE
  65.  
  66.    thomas@camino.mic.cl
  67.  
  68.