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 / MODEMS / MODEM2 / MODEM2.PRT < prev    next >
Text File  |  2000-06-30  |  7KB  |  160 lines
  1.                  MODEM/XMODEM Protocol Explained
  2.                 by Kelly Smith, CP/M-Net "SYSOP"
  3.                          January 8,1980
  4.                    Edited April 28, 1981 - FJW
  5.            Edited  July 17, 1985 - KBP
  6.  
  7.      I  thought  that it may be of some interest to those of  you 
  8. who use the MODEM/XMODEM file transfer capability to get a little 
  9. insight  as  to the communications  protocol  (i.e.  "handshaking 
  10. method") used by the system. 
  11.  
  12.      Herein lie the details of a very good (but not perfect) data 
  13. communications  protocol that has become the "de facto"  standard 
  14. for  various  remote CP/M systems (RCPM's) which  are  accessible 
  15. across  the country.   (Refer to RCPMLSTx.DOC on all  RCPM's  for 
  16. access  numbers and note that the "x" in that list changes as new 
  17. system  are  listed).   I  also  wish  to  give  credit  to  Ward 
  18. Christensen  (the "original" CBBS) for writing  MODEM.ASM  (CPMUG 
  19. Volume 25.11) and Keith Petersen,  Bruce Ratoff,  Dave Hardy, Rod 
  20. Hart,  Tom  "C"  (we  know who you are  Tom!),  and  others,  for 
  21. enhancements to Ward's original program which we now call  XMODEM 
  22. (external modem).
  23.  
  24.      Data is sent in 128-byte sequentially numbered blocks,  with 
  25. a single checksum byte appended to the end of each block.  As the 
  26. receiving  computer acquires the incoming data,  it performs  its 
  27. own  checksum  and upon each completion of a block,  it  compares 
  28. its  checksum result with that of the sending computers.   If the 
  29. receiving computer matches the checksum of the sending  computer, 
  30. it   transmits   an  ACK  (ASCII  code  protocol  character   for 
  31. ACKNOWLEDGE  (04 Hex,  Control-F)) back to the sending  computer.  
  32. The  ACK  therefore  means "all's well on  this  end,  send  some 
  33. more...".
  34.  
  35. Notice in the following example,  that the sending computer  will 
  36. transmit  an "initial NAK" (ASCII protocol character for NEGATIVE 
  37. ACKNOWLEDGE (15 Hex,  Control-U))...or, "that wasn't quite right, 
  38. please send again".
  39.  
  40. Due  to the asynchronous nature of the initial "hook-up"  between 
  41. the two computers, the receiving computer will "time-out" looking 
  42. for data,  and send the NAK as the "cue" for the sending computer 
  43. to  begin  transmission.   The sending computer  knows  that  the 
  44. receiving computer will "time-out", and uses this fact to "get in 
  45. sync"...  The sending computer responds to the "initial NAK" with 
  46. a  SOH  (ASCII code protocol character for START OF  HEADING  (01 
  47. Hex,  Control-A)),  sends  the first block number,  sends the 1's 
  48. complement  of the block number (VERY important,  I will  discuss 
  49. this later...),  sends 128 bytes of 8 bit data (that's why we can 
  50. transfer  ".COM"  files),  and  finally  a  checksum,  where  the 
  51. checksum is calculated by summing the SOH,  the block number, the 
  52. block number 1's complement, and the 128 bytes of data.
  53.  
  54. Receiving Computer:
  55.  
  56. ----/NAK/------------------------/ACK/----------------------
  57.     15H                           06H 
  58.  
  59. Sending Computer:
  60.  
  61. --------/SOH/BLK#/BLK#/DATA/CSUM/---/SOH/BLK#/BLK#/DATA/etc.
  62.          01H 001H 0FEH 8bit 8bit     01H 002H 0FDH 8bit .... 
  63.  
  64.      This  process continues,  with the next 128  bytes,  IF  the 
  65. block  was  ACK'ed by the receiving computer,  and then the  next 
  66. sequential block number and its 1's complement, etc.
  67.  
  68.      But  what  happens if the block  is  NAK'ed?...   Easy,  the 
  69. sending computer just re-sends the previous block.
  70.  
  71.      Now the hard part...  What if the sending computer transmits 
  72. a block, the receiving computer gets it and sends an ACK, but the 
  73. sender does not see it?...   The sending computer thinks that  it 
  74. has  failed  and  after  10  seconds  re-transmits  the  block...  
  75. ARGH!...  The receiving computer has "stashed" the data in memory 
  76. or  on disk (data is written to disk after receiving 16  blocks), 
  77. the  receiving  computer is now 1 block AHEAD of the  transmiting 
  78. computer!   Here comes the operation of the block numbers...  The 
  79. receiver  detects that this is the last block (all  over  again), 
  80. and   transmits  back  an  ACK,   throws  away  the  block,   and  
  81. (effectively)  "catches  up"...    clever!    What's  more,   the 
  82. integrity  of  the  block number is  verified  by  the  receiving 
  83. computer,  because  it  "sums"  the SOH (01 Hex) with  the  block 
  84. number  plus  the 1's complement of the block  number),  and  the 
  85. result  MUST BE zero for a proper transfer (e.g.  01+01+FE hex  = 
  86. 00, on the first block).  The sequence of events then, looks like 
  87. this: 
  88.  
  89. Receiving Computer:
  90.  
  91. ----/ACK/-----------------------/NAK/-----------------------
  92.     06H                          15H 
  93.  
  94. Sending Computer:
  95.  
  96. CSUM/---/SOH/BLK#/BLK#/DATA/CSUM/---/SOH/BLK#/BLK#/DATA/etc.
  97. 8bit     01H 003H 0FCH 8bit 8bit     01H 003H 0FCH 8bit ....
  98.  
  99.      Normal completion of data transfers will then conclude  with 
  100. an EOT (ASCII code protocol END OF TRANSMISSION, 04 Hex, Control-
  101. D) from the sending computer,  and a final ACK from the receiving 
  102. computer.   Unfortunately,  if  the receiving computer misses the 
  103. EOT,  it will continue to wait for the next block (sending a  NAK 
  104. every  10  seconds,  up to 10 times) and  eventually  "time-out".  
  105. This is rarely the case however, and although not "bullet-proof", 
  106. it is a very workable protocol.
  107.  
  108. Receiving Computer:
  109.  
  110. ----/ACK/---/ACK/"Transfer Complete"/A>(or B>)
  111.      06H     06H .............................
  112.  
  113. Sending Computer:
  114.  
  115. CSUM/---/EOT/---/A>(or B>)
  116. 8bit     04H .............
  117.  
  118.      In   some  cases,   where  the  telephone  transmission   is 
  119. repeatedly "trashed" (weak signals, multiple noise "hits", etc.), 
  120. the receiving computer (and operator) will be provided the option 
  121. to  quit.   Here,  the operator enters "R" or "Q" in response  to 
  122. "Retry or Quit?" (after 10 retries).
  123.  
  124. Receiving Computer:
  125.  
  126. ----/NAK/...NAK's ten times.../"Retry or Quit?"(Q)/A>...
  127.      15H
  128.  
  129. Sending Computer:
  130.  
  131. CSUM/---/...Garbled Data....../-----------------------/A>...
  132. 8bit
  133.  
  134.      A  final  consideration when using the MODEM program,  is  a 
  135. timing  related  problems when transfer  status  messages  and/or 
  136. textual  data  is directed to the screen of a slow (4800 Baud  or 
  137. less)  terminal  or  to a hard copy  printer.   This  problem  is 
  138. readily apparent (multiple NAK's) when using MODEM for the  first 
  139. time, and can usually be "cured" by NOT SPECIFYING the "V" (VIEW) 
  140. sub-option  when sending or receiving files.   Users of  Lifeboat 
  141. Associates  BSTAM encounter the same problem,  but this is easily 
  142. fixed  with  the  files  TQPATCH.ASM  and  RQPATCH.ASM  (transfer 
  143. quiet/receive quiet) that Keith Petersen  (Royal Oak RCPM  remote
  144. system,  (313)-759-6569) wrote to solve the  problem of low speed
  145. terminal  I/O.  Later versions  of  MODEM fixed  this problem  by
  146. printing  the status  message  before transmitting the ACK to the
  147. sender.
  148.  
  149.      For  users of CBBS's that do not have MODEM.ASM (but DO HAVE 
  150. a CP/M disk system...ESSENTIAL!),  let me suggest that you  "data 
  151. capture" the file MBOOT3.ASM from one of the RCPM's (it's a small 
  152. 8  kilo-byte file that "fits" in most systems' memory) to get the 
  153. larger  MODEM.ASM (40 kilo-bytes).   Check it very carefully  for 
  154. errors  using the "data capture" (read ERROR PRONE method  here). 
  155. Then edit and assemble for your modem configuration.
  156.  
  157.      If  you are tired of buying software where the  advertisment 
  158. is written better than the program, then the RCPM's are just what 
  159. you have been looking for...and FREE!
  160.