home *** CD-ROM | disk | FTP | other *** search
/ High Voltage Shareware / high1.zip / high1 / DIR10 / WXYZMODM.ZIP / XMODEM.DOC < prev    next >
Text File  |  1990-10-02  |  16KB  |  405 lines
  1.    Table of Contents
  2.  
  3. 1. DEFINITIONS
  4. 2. TRANSMISSION MEDIUM LEVEL PROTOCOL
  5. 3. MESSAGE BLOCK LEVEL PROTOCOL
  6. 4. FILE LEVEL PROTOCOL
  7. 5. DATA FLOW EXAMPLE INCLUDING ERROR RECOVERY
  8. 6. PROGRAMMING TIPS.
  9.  
  10. -------- 1. DEFINITIONS.
  11.  
  12.   <soh> 01H   <eot> 04H   <ack> 06H   <nak> 15H   <can> 18H
  13.  
  14. -------- 2. TRANSMISSION MEDIUM LEVEL PROTOCOL
  15. Asynchronous, 8 data bits, no parity, one stop bit.
  16.  
  17.     The protocol imposes no restrictions on the contents of the
  18. data being transmitted.  No control characters are looked for
  19. in the 128-byte data messages.    Absolutely any kind of data may
  20. be sent - binary, ASCII, etc.  The protocol has not formally
  21. been adopted to a 7-bit environment for the transmission of
  22. ASCII-only (or unpacked-hex) data , although it could be simply
  23. by having both ends agree to AND the protocol-dependent data
  24. with 7F hex before validating it.  I specifically am referring
  25. to the checksum, and the block numbers and their ones-
  26. complement.
  27.     Those wishing to maintain compatibility of the CP/M file
  28. structure, i.e. to allow modemming ASCII files to or from CP/M
  29. systems should follow this data format:
  30.   * ASCII tabs used (09H); tabs set every 8.
  31.   * Lines terminated by CR/LF (0DH 0AH)
  32.   * End-of-file indicated by ^Z, 1AH.  (one or more)
  33.   * Data is variable length, i.e. should be considered a
  34.     continuous stream of data bytes, broken into 128-byte
  35.     chunks purely for the purpose of transmission.
  36.   * A CP/M "peculiarity": If the data ends exactly on a
  37.     128-byte boundary, i.e. CR in 127, and LF in 128, a
  38.     subsequent sector containing the ^Z EOF character(s)
  39.     is optional, but is preferred.  Some utilities or
  40.     user programs still do not handle EOF without ^Zs.
  41.   * The last block sent is no different from others, i.e.
  42.     there is no "short block".
  43.  
  44. -------- 3. MESSAGE BLOCK LEVEL PROTOCOL
  45.  Each block of the transfer looks like:
  46. <SOH><blk #><255-blk #><--128 data bytes--><cksum>
  47.     in which:
  48. <SOH>        = 01 hex
  49. <blk #>     = binary number, starts at 01 increments by 1, and
  50.           wraps 0FFH to 00H (not to 01)
  51. <255-blk #> = blk # after going thru 8080 "CMA" instr, i.e.
  52.           each bit complemented in the 8-bit block number.
  53.           Formally, this is the "ones complement".
  54. <cksum>     = the sum of the data bytes only.  Toss any carry.
  55.  
  56. -------- 4. FILE LEVEL PROTOCOL
  57.  
  58. ---- 4A. COMMON TO BOTH SENDER AND RECEIVER:
  59.  
  60.     All errors are retried 10 times.
  61.     Some versions of the protocol use <can>, ASCII ^X, to
  62. cancel transmission.  This was never adopted as a standard, as
  63. having a single "abort" character makes the transmission
  64. susceptible to false termination due to an <ack> <nak> or <soh>
  65. being corrupted into a <can> and cancelling transmission.
  66.     The protocol may be considered "receiver driven", that is,
  67. the sender need not automatically re-transmit, although it does
  68. in the current implementations.
  69.  
  70. ---- 4B. RECEIVE PROGRAM CONSIDERATIONS:
  71.     The receiver has a 10-second timeout.  It sends a <nak>
  72. every time it times out.  The receiver's first timeout, which
  73. sends a <nak>, signals the transmitter to start.  Optionally,
  74. the receiver could send a <nak> immediately, in case the sender
  75. was ready.  This would save the initial 10 second timeout.
  76. However, the receiver MUST continue to timeout every 10 seconds
  77. in case the sender wasn't ready.
  78.     Once into a receiving a block, the receiver goes into a
  79. one-second timeout for each character and the checksum.  If the
  80. receiver wishes to <nak> a block for any reason (invalid
  81. header, timeout receiving data), it must wait for the line to
  82. clear.    See "programming tips" for ideas
  83.     Synchronizing:  If a valid block number is received, it
  84. will be: 1) the expected one, in which case everything is fine;
  85. or 2) a repeat of the previously received block.  This should
  86. be considered OK, and only indicates that the receivers <ack>
  87. got glitched, and the sender re-transmitted; 3) any other block
  88. number indicates a fatal loss of synchronization, such as the
  89. rare case of the sender getting a line-glitch that looked like
  90. an <ack>.  Abort the transmission, sending a <can>
  91.  
  92. ---- 4C. SENDING PROGRAM CONSIDERATIONS.
  93.  
  94.     While waiting for transmission to begin, the sender has
  95. only a single very long timeout, say one minute.  In the
  96. current protocol, the sender has a 10 second timeout before
  97. retrying.  I suggest NOT doing this, and letting the protocol
  98. be completely receiver-driven.    This will be compatible with
  99. existing programs.
  100.     When the sender has no more data, it sends an <eot>, and
  101. awaits an <ack>, resending the <eot> if it doesn't get one.
  102. Again, the protocol could be receiver-driven, with the sender
  103. only having the high-level 1-minute timeout to abort.
  104.  
  105.  
  106. -------- 5. DATA FLOW EXAMPLE INCLUDING ERROR RECOVERY
  107.  
  108. Here is a sample of the data flow, sending a 3-block message.
  109. It includes the two most common line hits - a garbaged block,
  110. and an <ack> reply getting garbaged.  <xx> represents the
  111. checksum byte.
  112.  
  113. SENDER                    RECEIVER
  114.                 times out after 10 seconds,
  115.             <---        <nak>
  116. <soh> 01 FE -data- <xx> --->
  117.             <---        <ack>
  118. <soh> 02 FD -data- xx    --->    (data gets line hit)
  119.             <---        <nak>
  120. <soh> 02 FD -data- xx    --->
  121.             <---        <ack>
  122. <soh> 03 FC -data- xx    --->
  123.    (ack gets garbaged)  <---            <ack>
  124. <soh> 03 FC -data- xx    --->        <ack>
  125. <eot>            --->
  126.             <---        <ack>
  127.  
  128. -------- 6. PROGRAMMING TIPS.
  129.  
  130. * The character-receive subroutine should be called with a
  131. parameter specifying the number of seconds to wait.  The
  132. receiver should first call it with a time of 10, then <nak> and
  133. try again, 10 times.
  134.   After receiving the <soh>, the receiver should call the
  135. character receive subroutine with a 1-second timeout, for the
  136. remainder of the message and the <cksum>.  Since they are sent
  137. as a continuous stream, timing out of this implies a serious
  138. like glitch that caused, say, 127 characters to be seen instead
  139. of 128.
  140.  
  141. * When the receiver wishes to <nak>, it should call a "PURGE"
  142. subroutine, to wait for the line to clear.  Recall the sender
  143. tosses any characters in its UART buffer immediately upon
  144. completing sending a block, to ensure no glitches were mis-
  145. interpreted.
  146.   The most common technique is for "PURGE" to call the
  147. character receive subroutine, specifying a 1-second timeout,
  148. and looping back to PURGE until a timeout occurs.  The <nak> is
  149. then sent, ensuring the other end will see it.
  150.  
  151. * You may wish to add code recommended by John Mahr to your
  152. character receive routine - to set an error flag if the UART
  153. shows framing error, or overrun.  This will help catch a few
  154. more glitches - the most common of which is a hit in the high
  155. bits of the byte in two consecutive bytes.  The <cksum> comes
  156. out OK since counting in 1-byte produces the same result of
  157. adding 80H + 80H as with adding 00H + 00H.
  158.  
  159. --------------------------------------------------------------
  160.  
  161.  
  162. MODEM PROTOCOL OVERVIEW,  CRC OPTION ADDENDUM
  163.  
  164. 1/13/85 by John Byrns.
  165. Please pass on any reports of errors in this document or suggestions
  166. for improvement to me via Ward's/CBBS at (312) 849-1132, or by voice
  167. at (312) 885-1105.
  168.  
  169. Last Rev: (preliminary  1/13/85)
  170.  
  171. This document describes the changes to the Christensen Modem Protocol
  172. that implement the CRC option. This document is an addendum to
  173. Ward Christensen's "Modem Protocol Overview". This document and
  174. Ward's document are both required  for a complete description of the
  175. Modem Protocol.
  176.  
  177.     Table of Contents
  178.  
  179. 1.  DEFINITIONS
  180. 7.  OVERVIEW OF CRC OPTION
  181. 8.  MESSAGE BLOCK LEVEL PROTOCOL, CRC MODE
  182. 9.  CRC CALCULATION
  183. 10. FILE LEVEL PROTOCOL, CHANGES FOR COMPATIBILITY
  184. 11. DATA FLOW EXAMPLES WITH CRC OPTION
  185.  
  186.  
  187. ---- 1B. ADDITIONAL DEFINITIONS
  188.  
  189. <C>    43H
  190.  
  191. -------- 7. OVERVIEW OF CRC OPTION
  192.  
  193. The CRC used in the Modem Protocol is an alternate form of block check
  194. which provides more robust error detection than the original checksum.
  195. Andrew S. Tanenbaum says in his book, Computer Networks, that the
  196. CRC-CCITT used by the Modem Protocol will detect all single and double
  197. bit errors, all errors with an odd number of bits, all burst errors of
  198. length 16 or less, 99.997% of 17-bit error bursts, and 99.998% of
  199. 18-bit and longer bursts.
  200.  
  201. The changes to the Modem Protocol to replace the checksum with the CRC
  202. are straight forward. If that were all that we did we would not be
  203. able to communicate between a program using the old checksum protocol
  204. and one using the new CRC protocol. An initial handshake was added to
  205. solve this problem. The handshake allows a receiving program with CRC
  206. capability to determine whether the sending program supports the CRC
  207. option, and to switch it to CRC mode if it does. This handshake is
  208. designed so that it will work properly with programs which implement
  209. only the original protocol. A description of this handshake is
  210. presented in section 10.
  211.  
  212. -------- 8. MESSAGE BLOCK LEVEL PROTOCOL, CRC MODE
  213.  
  214.  Each block of the transfer in CRC mode looks like:
  215. <SOH><blk #><255-blk #><--128 data bytes--><CRC hi><CRC lo>
  216.     in which:
  217. <SOH>          = 01 hex
  218. <blk #>     = binary number, starts at 01 increments by 1, and
  219.           wraps 0FFH to 00H (not to 01)
  220. <255-blk #> = ones complement of blk #.
  221. <CRC hi>    = byte containing the 8 hi order coefficients of the CRC.
  222. <CRC lo>    = byte containing the 8 lo order coefficients of the CRC.
  223.           See the next section for CRC calculation.
  224.  
  225. -------- 9. CRC CALCULATION
  226.  
  227. ---- 9A. FORMAL DEFINITION OF THE CRC CALCULATION
  228.  
  229. To calculate the 16 bit CRC the message bits are considered to be the
  230. coefficients of a polynomial. This message polynomial is first
  231. multiplied by X^16 and then divided by the generator polynomial
  232. (X^16 + X^12 + X^5 + 1) using modulo two arithemetic. The remainder
  233. left after the division is the desired CRC. Since a message block in
  234. the Modem Protocol is 128 bytes or 1024 bits, the message polynomial
  235. will be of order X^1023. The hi order bit of the first byte of the
  236. message block is the coefficient of X^1023 in the message polynomial.
  237. The lo order bit of the last byte of the message block is the
  238. coefficient of X^0 in the message polynomial.
  239.  
  240. ---- 9B. EXAMPLE OF CRC CALCULATION WRITTEN IN C
  241.  
  242. /*
  243. This function calculates the CRC used by the "Modem Protocol"
  244. The first argument is a pointer to the message block. The second
  245. argument is the number of bytes in the message block. The message
  246. block used by the Modem Protocol contains 128 bytes.
  247. The function return value is an integer which contains the CRC. The
  248. lo order 16 bits of this integer are the coefficients of the CRC. The
  249. The lo order bit is the lo order coefficient of the CRC.
  250. */
  251.  
  252. int calcrc(ptr, count) char *ptr; int count; {
  253.  
  254.     int crc, i;
  255.  
  256.     crc = 0;
  257.     while(--count >= 0) {
  258.     crc = crc ^ (int)*ptr++ << 8;
  259.     for(i = 0; i < 8; ++i)
  260.         if(crc & 0x8000)
  261.         crc = crc << 1 ^ 0x1021;
  262.         else
  263.         crc = crc << 1;
  264.     }
  265.     return (crc & 0xFFFF);
  266.     }
  267.  
  268. -------- 10. FILE LEVEL PROTOCOL, CHANGES FOR COMPATIBILITY
  269.  
  270. ---- 10A. COMMON TO BOTH SENDER AND RECEIVER:
  271.  
  272. The only change to the File Level Protocol for the CRC option is the
  273. initial handshake which is used to determine if both the sending and
  274. the receiving programs support the CRC mode. All Modem Programs should
  275. support the checksum mode for compatibility with older versions.
  276. A receiving program that wishes to receive in CRC mode implements the
  277. mode setting handshake by sending a <C> in place of the initial <nak>.
  278. If the sending program supports CRC mode it will recognize the <C> and
  279. will set itself into CRC mode, and respond by sending the first block
  280. as if a <nak> had been received. If the sending program does not
  281. support CRC mode it will not respond to the <C> at all. After the
  282. receiver has sent the <C> it will wait up to 3 seconds for the <soh>
  283. that starts the first block. If it receives a <soh> within 3 seconds
  284. it will assume the sender supports CRC mode and will proceed with the
  285. file exchange in CRC mode. If no <soh> is received within 3 seconds
  286. the receiver will switch to checksum mode, send a <nak>, and proceed
  287. in checksum mode. If the receiver wishes to use checksum mode it
  288. should send an initial <nak> and the sending program should respond to
  289. the <nak> as defined in the original Modem Protocol. After the mode
  290. has been set by the initial <C> or <nak> the protocol follows the
  291. original Modem Protocol and is identical whether the checksum or CRC
  292. is being used.
  293.  
  294. ---- 10B. RECEIVE PROGRAM CONSIDERATIONS:
  295.  
  296. There are at least 4 things that can go wrong with the mode setting
  297. handshake.
  298.   1. the initial <C> can be garbled or lost.
  299.   2. the initial <soh> can be garbled.
  300.   3. the initial <C> can be changed to a <nak>.
  301.   4. the initial <nak> from a receiver which wants to receive in
  302.      checksum can be changed to a <C>.
  303.  
  304. The first problem can be solved if the receiver sends a second <C>
  305. after it times out the first time. This process can be repeated
  306. several times. It must not be repeated a too many times before sending
  307. a <nak> and switching to checksum mode or a sending program without
  308. CRC support may time out and abort. Repeating the <C> will also fix
  309. the second problem if the sending program cooperates by responding as
  310. if a <nak> were received instead of ignoring the extra <C>.
  311.  
  312. It is possible to fix problems 3 and 4 but probably not worth the
  313. trouble since they will occur very infrequently. They could be fixed
  314. by switching modes in either the sending or the receiving program
  315. after a large number of successive <nak>s. This solution would risk
  316. other problems however.
  317.  
  318. ---- 10C. SENDING PROGRAM CONSIDERATIONS.
  319.  
  320. The sending program should start in the checksum mode. This will
  321. insure compatibility with checksum only receiving programs. Anytime a
  322. <C> is received before the first <nak> or <ack> the sending program
  323. should set itself into CRC mode and respond as if a <nak> were
  324. received. The sender should respond to additional <C>s as if they were
  325. <nak>s until the first <ack> is received. This will assist the
  326. receiving program in determining the correct mode when the <soh> is
  327. lost or garbled. After the first <ack> is received the sending program
  328. should ignore <C>s.
  329.  
  330. -------- 11. DATA FLOW EXAMPLES WITH CRC OPTION
  331.  
  332. ---- 11A. RECEIVER HAS CRC OPTION, SENDER DOESN'T
  333.  
  334. Here is a data flow example for the case where the receiver requests
  335. transmission in the CRC mode but the sender does not support the CRC
  336. option. This example also includes various transmission errors.
  337. <xx> represents the checksum byte.
  338.  
  339. SENDER                    RECEIVER
  340.             <---        <C>
  341.                 times out after 3 seconds,
  342.             <---        <nak>
  343. <soh> 01 FE -data- <xx> --->
  344.             <---        <ack>
  345. <soh> 02 FD -data- <xx> --->    (data gets line hit)
  346.             <---        <nak>
  347. <soh> 02 FD -data- <xx> --->
  348.             <---        <ack>
  349. <soh> 03 FC -data- <xx> --->
  350.    (ack gets garbaged)  <---            <ack>
  351.                 times out after 10 seconds,
  352.             <---        <nak>
  353. <soh> 03 FC -data- <xx> --->
  354.             <---        <ack>
  355. <eot>            --->
  356.             <---        <ack>
  357.  
  358. ---- 11B. RECEIVER AND SENDER BOTH HAVE CRC OPTION
  359.  
  360. Here is a data flow example for the case where the receiver requests
  361. transmission in the CRC mode and the sender supports the CRC option.
  362. This example also includes various transmission errors.
  363. <xxxx> represents the 2 CRC bytes.
  364.  
  365. SENDER                      RECEIVER
  366.               <---          <C>
  367. <soh> 01 FE -data- <xxxx> --->
  368.               <---          <ack>
  369. <soh> 02 FD -data- <xxxx> --->      (data gets line hit)
  370.               <---          <nak>
  371. <soh> 02 FD -data- <xxxx> --->
  372.               <---          <ack>
  373. <soh> 03 FC -data- <xxxx> --->
  374.    (ack gets garbaged)    <---            <ack>
  375.                   times out after 10 seconds,
  376.               <---          <nak>
  377. <soh> 03 FC -data- <xxxx> --->
  378.               <---          <ack>
  379. <eot>              --->
  380.               <---          <ack>
  381. --
  382.     Dave Ihnat
  383.     Analysts International Corporation
  384.     (312) 882-4673
  385.     ihnp4!aicchi!ignatz
  386.  
  387.  
  388.  
  389. ----------XMODEM SOURCES-------
  390.  
  391. Ward's/CBBS at 312-849-1132
  392. XMODEM-CRC document 1/13/85 by John Byrns. Voice: 312-885-1105
  393. Dave Ihnat, Analysts International Corporation    : 312-882-4673
  394. ihnp4!aicchi!ignatz
  395.  
  396. Protocall docs are also available from:
  397.  
  398. Chuck Forsberg WA7KGX
  399. tektronix!reed!omen!caf  Omen Technology Inc "The High Reliability Software"
  400. 17505-V Northwest Sauvie Island Road Portland OR 97231    Voice: 503-621-3406
  401. TeleGodzilla BBS: 621-3746 2400/1200  CIS:70007,2304  Genie:CAF
  402. Source:TCE022
  403. omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp
  404. omen!/usr/spool/uucppublic/FILES lists all uucp-able files, updated hourly
  405.