home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / dcom / modems / 13102 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  2.8 KB
  1. Xref: sparky comp.dcom.modems:13102 comp.mail.uucp:1769
  2. Path: sparky!uunet!airs!ian
  3. From: ian@airs.com (Ian Lance Taylor)
  4. Newsgroups: comp.dcom.modems,comp.mail.uucp
  5. Subject: Re: UUCP 'G' protocol packet size
  6. Message-ID: <5259@airs.com>
  7. Date: 8 Sep 92 04:45:15 GMT
  8. References: <1079@bazooka.amb.org> <kouqqB4w165w@zswamp.UUCP>
  9. Sender: news@airs.com
  10. Followup-To: comp.dcom.modems
  11. Lines: 51
  12.  
  13. geoff@zswamp.UUCP (Geoffrey Welsh) writes:
  14.  
  15. >ti@bazooka.amb.org (Ti Kan) writes:
  16.  
  17. >> So the question is, is there any benefit in increasing
  18. >> this to something like 4096 bytes?  Do I run the risk of making my
  19. >> uucico incompatible with other systems?
  20.  
  21. >   First of all, you're confusing UUCP-g with UUCP-G protocols.  The larger G 
  22. >protocol was designed to allow varied window and block size, while g protocol 
  23. >is usually implemented with, as you observed, fixed block size.
  24.  
  25. This is true from a certain point of view, but I think it needs
  26. clarification.  In my experience, most UUCP 'g' protocols support any
  27. window or block size, when requested by the remote system.  The ones
  28. which don't are the exception.  The real difference is that the SVR4
  29. 'G' protocol provides an easy way to change the window and block size
  30. which your system requests, whereas most 'g' protocol implementations
  31. do not.
  32.  
  33. If your 'g' implementation lets you choose the window and block size,
  34. you can often increase it with no difficulties, depending on what is
  35. running on the remote system.
  36.  
  37. Moreover, every 'g' implementation that I am aware of will accept
  38. varying block sizes in a single conversation, up to the requested
  39. limit.  The SVR4 'G' implementation will not; every block sent must be
  40. of the same size, which is surprisingly bad when using large block
  41. sizes.
  42.  
  43. >   Increasing the block size will increase the window size, and that will help 
  44. >increase throughput where significant latency is involved.  However, it is not 
  45. >compatible with most uucicos which don't support G protocol and have an 
  46. >inflexible g protocol block size.
  47.  
  48. I believe that the latter is a limited set, and that it does not
  49. include any version of HDB UUCP.
  50.  
  51. >It's also incompatible with Telebit (and 
  52. >probably Microcom and others) spoofing, which will do more for throughput than 
  53. >larger blocks because they effectively turn UUCP-g into a streaming protocol 
  54. >where it counts.
  55.  
  56. You are normally better off spoofing if you have a modem which
  57. supports spoofing, but I believe you can do better than Telebit 2500
  58. spoofing by making a V.42bis connection with a 1024 byte block size.
  59. -- 
  60. Ian Lance Taylor                ian@airs.com                 uunet!airs!ian
  61. First person to identify this quote wins a free e-mail message:
  62. ``He caught the lady in this way: so when the lady was running away for her
  63.   life, he hastily ran to her front and stopped her as a log of wood.''
  64.