home *** CD-ROM | disk | FTP | other *** search
/ Hacker Chronicles 2 / HACKER2.BIN / 972.XPACKET.PRO < prev    next >
Text File  |  1988-03-07  |  2KB  |  51 lines
  1.                         XPACKET PROTOCOL
  2.                      by: Carl Moreschi, N4PY
  3.  
  4.  
  5. This documemnt decribes a protocol to be used with Packet Radio to transfer
  6. binary files in an efficient manner.  The protocol gets its roots from XMODEM
  7. protocol and attempts to alter and enhance that protocol to better fit the
  8. packet radio environment.
  9.  
  10. The protocol is simple and is receiver driven. It goes like this:
  11.  
  12. 1.  The receiver initiates the transfer by sending NAK (21) to the sender to
  13.     signify ready.  The NAK is repeated every 30 seconds until a packet is
  14.     received from the sender.
  15.  
  16. 2.  When the sender receives the NAK, the sender sends the file header to the
  17.     receiver.  The file header looks like this:
  18.  
  19.      SOH            one byte (value 01)
  20.      Filename       varible bytes consisting of the file
  21.                     name and extender in ascii
  22.  
  23. 3.  The sender then follows the header immediately with the file data blocks.
  24.     A file data block is up to 130 bytes and appears as follows:
  25.  
  26.      STX            one byte (value 02)
  27.      Count          one byte (value 01 to 128, usually 128)
  28.      Data           data bytes (1 to 128 bytes according to count)
  29.  
  30. 4.  The sender continues to send data blocks with 128 bytes of data until the
  31.     end of file is reached.  The last block may be less then 128 bytes.  When
  32.     all the data blocks have been sent, the sender finishes the transfer by
  33.     sending an ending sequence as follows:
  34.  
  35.      EOT            one byte (value 04)
  36.  
  37. 5.  While the sender is sending out the blocks of data, the sender checks
  38.     between blocks for receiving a CAN (24).  If a CAN is received the
  39.     transmission is aborted.  In addition the sender may abort the transfer by
  40.     sending a CAN as a one byte block to the receiver.  Thus either side may
  41.     abort the transfer.
  42.  
  43. 6.  The receiver receives the file header and data blocks and builds a
  44.     corresponding file.  It is the option of the receiver to name the newly
  45.     received file the same as the file header name or name the newly received
  46.     file some other name.
  47.  
  48.                                  Carl Moreschi
  49.                                  N4PY
  50.                                  October 6, 1985
  51.