home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / dcom / modems / 13162 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  2.0 KB
  1. Path: sparky!uunet!sun-barr!ames!data.nas.nasa.gov!taligent!apple!ntg!dplatt
  2. From: dplatt@ntg.com (Dave Platt)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: UUCP 'G' protocol packet size
  5. Message-ID: <1992Sep9.173804.28612@ntg.com>
  6. Date: 9 Sep 92 17:38:04 GMT
  7. References: <1079@bazooka.amb.org> <kouqqB4w165w@zswamp.UUCP> <5259@airs.com>
  8. Organization: New Technologies Group, Inc.  Palo Alto CA
  9. Lines: 29
  10.  
  11. In article <5259@airs.com> ian@airs.com (Ian Lance Taylor) writes:
  12.  
  13. >Moreover, every 'g' implementation that I am aware of will accept
  14. >varying block sizes in a single conversation, up to the requested
  15. >limit.
  16.  
  17. Interesting - I've had almost the opposite experience.  Both SunOS 4.1.x
  18. uucp (a HDB variant), and ULTRIX uucp (whatever version APPLE.COM is
  19. currently running) seem to have hard-coded 64-byte-packet receivers.  If
  20. one tries to send them a shorter (32-byte) packet, neither one handles
  21. it properly... the packets are either rejected, or result in timeouts.
  22. I ended up deciding that "smart packet" mode (sending packets shorter
  23. than the limit) should be enabled only when the peer site sets a limit
  24. of 128 bytes or more.
  25.  
  26. On the other hand, Taylor uucp is remarkably tolerant... it not only
  27. accepts packets which are shorter than the negotiated limit, but it also
  28. accepts packets which are _longer_ than the requested limit.  I tried
  29. force-feeding it 256-byte packets, in a session which had requested a
  30. 64-byte limit, and it gobbled them down just fine.  Nice work, Ian!  [I
  31. know, I know, this technique is a revolting violation of protocol... but
  32. I haven't yet had the energy required to write up a set of Taylor-style
  33. configuration files which would enable g-protocol INIT negotiation of
  34. 256-byte packets... I'm still using HDB accomodation mode.]
  35.  
  36. -- 
  37. Dave Platt                                                VOICE: (415) 813-8917
  38.               Domain: dplatt@ntg.com      UUCP: ...netcomsv!ntg!dplatt
  39.  USNAIL: New Technologies Group Inc. 2468 Embarcardero Way, Palo Alto CA 94303
  40.