home *** CD-ROM | disk | FTP | other *** search
/ Programmer 7500 / MAX_PROGRAMMERS.iso / INFO / MISC / TNH_PC.ZIP / JORDAN.NL < prev    next >
Encoding:
Text File  |  1987-01-14  |  7.5 KB  |  226 lines

  1. Xmodem Protocol
  2.  
  3.              Larry Jordan
  4.         Capital PC Users Group
  5.  
  6. When using the telephone system to
  7. transfer files between computers,
  8. there is always the chance that
  9. electrical noise will cause data
  10. transmission errors.  To ensure
  11. proper transfer of files, it is
  12. necessary to detect data transmission
  13. errors and to retransmit data that
  14. contains errors.
  15.  
  16. Asynchronous parity error detection
  17. does not provide that capability.
  18. Parity error detection tells you when
  19. data transfer errors occur, and it's
  20. up to you to retransmit data to
  21. correct errors. The problem is that
  22. parity error detection is not
  23. actually performed by most IBM PC
  24. communication packages. If a package
  25. does perform the error detection, it
  26. may not inform you of errors in a way
  27. that lets you know immediately to
  28. retransmit the data. ASCOM, for
  29. example, places an asterisk in a file
  30. where parity errors are detected, but
  31. you may not realize the errors
  32. occurred until long after the file is
  33. transferred. To ensure "error-free"
  34. data transfer, a protocol file
  35. transfer technique is required.
  36.  
  37. A protocol is a set of rules and
  38. conventions that apply to a specific
  39. area of communications, allowing
  40. participants to properly communicate,
  41. regardless of the hardware brand or
  42. software package being used. The
  43. protocol file transfer is a set of
  44. rules for transferring files, which
  45. specifies a set of ASCII handshaking
  46. transfer functions. Protocol
  47. handshaking signals allow
  48. communications software to transfer
  49. text, data and machine code files,
  50. and to perform sophisticated
  51. error-checking. The handicap in using
  52. a protocol file transfer technique is
  53. that the computers on both ends of
  54. the communications link must use
  55. compatible software. There is no
  56. standard that controls these
  57. protocols and almost all
  58. communication packages that have a
  59. protocol file transfer option use a
  60. protocol unique to that package. This
  61. means that a group of people must
  62. standardize microcomputer
  63. communications software to take
  64. advantage of protocol transfers.
  65.  
  66. The Ward Christensen XMODEM protocol
  67. is one specific file transfer
  68. protocol that may become a default
  69. standard in personal communications,
  70. primarily because of its widespread
  71. use in bulletin boards and its
  72. inclusion in low-cost personal
  73. computer communications packages,
  74. such as PC-TALK. Users of
  75. communication software deserve a
  76. standard protocol allowing them to
  77. use the technique with any
  78. microcomputer, regardless of the
  79. software packages employed.
  80.  
  81. The XMODEM protocol is illustrated in
  82. Figure 1. As you can see from that
  83. figure, XMODEM does not begin to
  84. transfer data until the receiving
  85. computer signals the transmitting
  86. computer that it is ready to receive
  87. data. The Negative Acknowledge (NAK)
  88. character is sent to the transmitting
  89. computer every 10 seconds until the
  90. file transfer begins. If the file
  91. transfer does not begin after 9 NAK's
  92. are sent, the process has to be
  93. manually restarted.
  94.  
  95.               Figure 1
  96.  
  97.     XMODEM Protocol File Transfer
  98.  
  99. Receiving                Transmitting
  100. Computer                     Computer
  101. Ready to                     Ready to
  102. Receive                      Transmit
  103. +                                   +
  104. +                                   +
  105. + --------------/NAK/-------------- +
  106. +                                   +
  107. +-/SOH/Blk#1/Blk#1/Good Data/CkSum/-+
  108. +                                   +
  109. + --------------/ACK/-------------- +
  110. +                                   +
  111. +-/SOH/Blk#2/Blk#2/Good Data/CkSum/-+
  112. +                                   +
  113. + --------------/ACK/-------------- +
  114. +                                   +
  115. +/SOH/Blk#3/Blk#3/Garbled Data/Cksum+
  116. +                                   +
  117. + --------------/NAK/-------------- +
  118. +                                   +
  119. +-/SOH/Blk#3/Blk#3/Good Data/CkSum/ +
  120. +                                   +
  121. + --------------/ACK/-------------- +
  122. +                                   +
  123. + --------------/EOT/-------------- +
  124. +                                   +
  125. + --------------/ACK/-------------- +
  126. +                                   +
  127. V                                   V
  128. File                             File
  129. Receipt                      Transmit
  130. Ends                             Ends
  131.  
  132. Once a NAK is received, the
  133. transmitting computer uses a Start of
  134. Header (SOH) character and two block
  135. numbers (a true block number followed
  136. by a 1's complement of the number) to
  137. signal that a 128-byte block of data
  138. has started to transfer; it then
  139. sends the block followed by an
  140. error-checking checksum. The checksum
  141. is calculated by adding the ASCII
  142. values of each character in the 128
  143. character block; the sum is then
  144. divided by 255 and the remainder is
  145. retained as the checksum. After each
  146. block of data is transferred, the
  147. receiving computer calculates its
  148. checksum and compares the result to
  149. the checksum received from the
  150. transmitting computer. If the two
  151. values are the same, the receiving
  152. computer sends an Acknowledge(ACK)
  153. character to tell the receiver to
  154. send the next sequential block. If
  155. the two values are not the same, the
  156. receiving computer sends the
  157. transmitter a NAK to request a
  158. retransmission of the last block.
  159. This retransmission process is
  160. repeated until the block of data is
  161. properly received or until nine
  162. attempts have been made to transmit
  163. the block. If the communications link
  164. is noisy, resulting in improper block
  165. transmission after nine attempts, the
  166. file transfer is aborted.
  167.  
  168. XMODEM uses two block numbers at the
  169. start of each block to be sure the
  170. same block is not transmitted twice
  171. because of a handshake character loss
  172. during the transfer. The receiving
  173. computer checks the transmitted block
  174. to be sure that it is the one
  175. requested, and blocks that are
  176. retransmitted by mistake are thrown
  177. away. When all data has been
  178. successfully transmitted, the
  179. transmitting computer sends the
  180. receiver an End-of-Transmission (EOT)
  181. character to indicate end-of-file.
  182.  
  183. The XMODEM protocol offers the IBM PC
  184. several advantages over other
  185. protocols and file transfer methods.
  186. First, the protocol is in the public
  187. domain, so software designers tend to
  188. incorporate it into a communications
  189. package. Second, the protocol is easy
  190. to implement using high level
  191. languages such as BASIC or PASCAL.
  192. Third, the protocol requires only a
  193. 256-byte communications receive
  194. buffer, which makes it attractive for
  195. IBM PC owners who have 64K systems.
  196. Fourth, the protocol allows a user to
  197. transfer non-ASCII 8-bit data files
  198. (i.e., COM, EXE and tokenized BASIC)
  199. between microcomputers because it
  200. calculates the end of a file based on
  201. file size and uses handshake signals
  202. to indicate the end of a file instead
  203. of relying on an end of file marker
  204. character (control-Z) to terminate a
  205. file transfer. Fifth, XMODEM error
  206. checking is superior to normal
  207. asynchronous parity error checking.
  208. The parity method of error checking
  209. is 95 percent effective if the
  210. software on the receiving end checks
  211. for parity errors. XMODEM error
  212. checking is 99.6 percent effective,
  213. and the software on the receiving end
  214. must check for errors. Parity errors
  215. detected also do not result in
  216. automatic retransmission of the bad
  217. data; XMODEM detected errors result
  218. in data retransmission until no
  219. errors are detected or until nine
  220. retransmissions have been attempted.
  221. Finally, the protocol is used by most
  222. bulletin boards and having it in a
  223. communications package allows IBM PC
  224. users to receive error checked files
  225. from their bulletin boards.
  226.