home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / CPM / RCPM / 1KPACKET.DOC < prev    next >
Text File  |  2000-06-30  |  4KB  |  82 lines
  1.  
  2.             The new 1K packet option
  3.                 for
  4.              Christensen protocol transfers
  5.  
  6.  
  7. Why 1k packets?
  8.  
  9. With the current proliferation of 2400 baud modems, it has become obvious
  10. that throughput (i.e., efficiency) of file transfers could be higher if
  11. more data could be added to the fundamental unit of exchange (i.e., the
  12. "packet").  The reason for this is essentially the "stop and wait" nature
  13. of the Christensen protocol: send a packet, wait for an acknowledgement,
  14. send a packet, wait, etc.  When the packet size is relatively small, as
  15. it has always been with Christensen protocol, this "turn-around" time be-
  16. comes a significant portion of the total time necessary to transfer a file.
  17. If the medium through which the transfer is taking place exhibits its own
  18. delay, the problem is compounded (all transfer media -- even hardwired
  19. RS232 connections -- have some media delay; this delay is much more pro-
  20. nounced in satellite telephone connections and packet-switched networks,
  21. such as Arpanet and Compuserve).
  22.  
  23. Conversely, using a large packet size with an inherently noisy medium can
  24. not only destroy any gains realized by using a the larger packet, but can
  25. actually increase file transfer time, because retransmission of a large
  26. packet takes longer than retransmission of a small packet.
  27.  
  28. So it seems logical that any large-packet protocol must also have the
  29. ability to "fall back", in the face of line noise, to the small packets
  30. that are so much more efficient in the noisy environment.
  31.  
  32. MEX 1.40 implements this fallback feature; it uses nearly the same al-
  33. gorthm employed by Paul Homchick in his 1k-packet modifications to the
  34. public domain XMODEM program (version 10.8 at the time of this writing).
  35. Further, the 1K packet option is entirely user-selectable; if you don't
  36. want to use large packets, simply continue using MEX as you've always
  37. used it; there's no penalty for not using large packets.
  38.  
  39. If you prefer the higher efficiency (and noisy lines are not a problem
  40. for you), simply append a "K" to the the "T" command when you're SENDING
  41. a file with MEX 1.14.  In fact, you can make this change permanent by
  42. entering the command "GLOBAL K", then using the CLONE command to save
  43. your modified MEX to disk (be advised, however, that if you do this,
  44. you run the risk of not being able to exchange files with versions of
  45. XMODEM or MEX that do not have the 1k packet capability, without expressly
  46. turning off the GLOBAL K).
  47.  
  48. MEX, when receiving, is always prepared to receive 1k packets, in any
  49. mixture with 128-byte packets.  Thus, when you're preparing MEX to
  50. receive a file, you need take no special action (in fact, the 'K'
  51. option, while accepted, is ignored in a file receive).
  52.  
  53. MEX, when transmitting, will adjust for line noise; after the third
  54. (not necessarily consecutive) error has occurred, MEX will calculate the
  55. ratio of errors to "virtual" 128-byte packets.  If this ratio exceeds
  56. 1 error per each six 128-byte "virtual" packets, MEX will switch to
  57. 128-byte mode.  Note that MEX will NOT switch to 128-byte mode until
  58. the next successive packet, however.  Thus, once a packet has started
  59. as a 1k packet, it must finish as a 1k packet (otherwise, certain
  60. combinations of noise could cause the transfer to appear correct,
  61. but be received incorrectly).  If you're using the batch option, MEX
  62. will always switch back to 1k packets at the beginning of the next file.
  63.  
  64. Note that MEX 1.40 is fully compatible with the emerging YMODEM specif-
  65. ication authored by Chuck Forsberg of Omen Technology, insofar as 1K
  66. blocks are conerned (MEX does not "round up" an outgoing file to 1K,
  67. however -- it switches to 128-byte mode when the remaining outstanding
  68. byte count is less than 1024.  This is permitted by the YMODEM spec-
  69. ification).  
  70.  
  71. Progress reporting
  72.  
  73. You'll notice that while transferring files in 1k mode, MEX will print
  74. "logical" record numbers on the screen (actually the starting and end-
  75. ing record numbers of the 1k packet being sent or received).  Note that
  76. this is the 128-byte record number, and bears to relation to the packet
  77. number, which is part of the packet "envelope"; it increments by 1 for
  78. each 1k packet, and is of no consequence to the user.
  79.  
  80. ------------------------------------------------------------
  81.  
  82.