home *** CD-ROM | disk | FTP | other *** search
/ ftp.whtech.com / ftp.whtech.com.tar / ftp.whtech.com / club100 / ref / xmodem.doc < prev   
Text File  |  2006-10-19  |  5KB  |  79 lines
  1.     I'll first describe the vanilla xmodem protocol as originated by Ward
  2. Christensen for data exchange between CP/M microcomputers.  Then I'll
  3. touch on a couple of refinements that have been added over the years to
  4. allow for better error checking, faster transfers, and transfers of
  5. multiple files.  
  6.     All these protocols assume that eight-bit data is to be sent, and that
  7. no 8-bit pattern has any special significance.  That's the idea, to
  8. transfer any file whatsoever, be it data, a program or text.  The COM:
  9. settings will be 8N1D:  8 bits, no parity, 1 stop bit, X-on X-off disabled.
  10. ...........
  11.     Glossary of signals used in xmodem exchanges:
  12.     signal name    ascii character    CHR$(.)             meaning
  13.         NAK             ^U              21              non-acknowledge
  14.         ACK             ^F               6              acknowledge
  15.         SOH             ^A               1              start of header
  16.         EOT             ^D               4              end of transmission
  17.         CAN             ^X              24              cancel exchange
  18. ...........
  19.     In a vanilla Xmodem exchange each packet sent by the transmitter
  20. consists of 132 bytes.  The actual data is preceded by three bytes: first
  21. the SOH character, then the packet number, then the onesU complement of
  22. the packet number.  Then come the 128 data bytes.  That accounts for 131
  23. bytes.  The 132nd byte is the checksum, which is simply the arithmetic
  24. sum, modulo 256, of all the 128 data bytes.  The packet number commences
  25. with 1 for the first packet and increases modulo 256. If N is the packet
  26. number, then its ones' complement is calculated as (N XOR 255).
  27.     The receiver checks the 132 bytes to see that the first character is
  28. in fact  SOH, that the packet number and its complement agree and are in
  29. sequence, and that the checksum as computed by the receiver agrees with
  30. that sent by the transmitter.  After checking the packet and handling its
  31. filing, the receiver responds by sending either ACK, to acknowledge
  32. correct reception, or NAK to signal an error, or CAN to cancel the
  33. exchange.
  34.     The transmitter accordingly retransmits the previous packet, or a new
  35. one, or stops.
  36.     To commence the exchange and get the transmitter to send its first
  37. packet, the receiver sends out the NAK character.  It repeats sending the
  38. NAK at ten second intervals until the transmitter responds, or until a
  39. time limit is reached (usually one minute).
  40.      To finish off the exchange, after acknowledgement of the final
  41. packet, the transmitter sends the EOT character and waits for the receiver
  42. to respond with ACK and then goes on to its next task.  If the receiver
  43. responds with anything but ACK or CAN the transmitter tries again (up to a
  44. time limit) to send EOT until it does receive the ACK or CAN.
  45.     The ACK, NAK and EOT signals sent are repeated at ten second intervals
  46. (up to 6 or so tries) until the expected response occurs.
  47.  
  48.     The xmodem protocol is not without faults.  Transmitted data can be
  49. corrupted and still yield a match in the checksum.  In a channel with high
  50. levels of normally distributed noise, the error rate can theoretically
  51. approach 4%, and even worse for burst noise.  Error checking using a CRC
  52. (cyclic redundancy check) is more effective.  A variation of xmodem
  53. implements CRC error checking.  Sometimes the CRC is not at all necessary.
  54.  Phone channels are sometimes very, very good, and you can safely transfer
  55. data in longer packets, say, 1028 bytes instead of 128.  The transfer is
  56. then faster.  A variant of xmodem enables that.  Another optional feature
  57. allows you to transfer a bunch of files at once.  That is Ymodem, which in
  58. many ways is very much like xmodem.  These are topics for chapter 2 of
  59. these notes.  Usually, the programs are set up to recognize and respond to
  60. these alternative forms of xmodem automatically.
  61.     All of the  versions of xmodem assume an 8-bit channel for
  62. transferring data.  That is no insurmountable problem in transfers of data
  63. between microcomputers. But minis and mainframes are often very rigid and
  64. allow you only a seven bit channel, and even then they treat certain of
  65. the control characters in special ways.  In such cases, Kermit is the
  66. protocol of choice, rather than xmodem.  Another disadvantage of xmodem is
  67. that the packets are all of fixed length.  The final packet of a
  68. transmission may have to be padded at the end with some garbage.  The
  69. receiver or the operating system on the receiving end has to know how to
  70. deal with that.  Variable length packets also allow the packet length to
  71. adjust to the amount of noise on the line.  Kermit allows for variable
  72. length packets.
  73.  
  74.  
  75.     
  76.  
  77. by Tracy Allen, 2018 Parker St., Berkeley, CA 94704     (415)848-5725
  78. CIS 76670,326         Date  3/27/89   draft.
  79.