Please consider a donation to the Higher Intellect project. See https://preterhuman.net/donate.php or the Donate to Higher Intellect page for more info.

XModem protocol

From Higher Intellect Vintage Wiki
Jump to navigation Jump to search
+-------------------------------------------------------------------------+
!                                                                         !
!                 Lightning House Software Co. presents:                  !
!                         *** XModem protocol ***                         !
!                                                                         !
+-------------------------------------------------------------------------+

The XModem protocol in general:
-------------------------------
The XModem protocol is generally a simple way to transfer data files with
minimum errors which may occur due to line static charges etc. The XModem
protocol takes a file and cuts it into blocks. Each block is 128 bytes, and
every block has some data added to it like block number and checksum bytes.

A look at XModem's blocks:
--------------------------
Well, there arrises the question: what if the receiving computer gets
garbage before beginning transmission or block? Well, XModem defines one
character, SOH (01h), as the beginning-of-block sign. This char will be
referred to as SOH (Start Of Header). Any information sent before
the SOH is ignored. After this byte, (the SOH), the sender sends the block
number, beginning with one, as one byte, and after it, a complemenr byte.
(255-Block #). If the block number is greater than 255 it wraps around back
to zero.
 After the SOH, Block # and 255-Block #, 128 bytes of data are sent which
preceed the checksum (CKSM) byte.

A block should look like this:

-------------------------------------------------
!     !      !          !                !      !
! SOH ! Bl # ! 255-Bl # ! 128 data bytes ! CKSM !
!1    !1     !1         !128             !1     !
-------------------------------------------------
(The numbers on the bottom represent the number of bytes.)

The CheckSum byte:
------------------
The CKSM byte comes to find if an error has occured. The CKSM is calculated
by adding together all the 128 bytes of data, and taking the low byte.
(like doing: cksm = sum AND 255. Thus taking the lowest 8 bits.) If the
CKSM calculated by the receiver is compared to the one sent, and found
wrong a NAK is sent by the receiver to Negatively AcKnowledge the block,
and to ask for retransmission of the block.

Other Errors:
-------------
If the block count on the receiving side does not match the one on the
sending side, a retransmission is requested by sending NAK. If again the
count does not match, but the block # of the previous block is identical to
the one on the retransmitted block, then the transmission is aborted by the
CANcel byte being sent to the sender after the CKSM byte is received. The
CAN char is equivalent to CTRL-X.
 If the block number received, and the inverted block number (255-b#), do
not match, a retransmission is requested by the NAK character.
 If the receiver gets a CAN while waiting for NAK on the beginning of a
block, transmission is aborted.

EOT - End Of Transmission:
--------------------------
When the sender gets to the end of his file, he sends nulls, Hex 00, to
fill the 128 byte block, and calculates the CKSM with the nulls. After this
block the sender sends an EOT char CTRL-D and ends the transmission.

ACKnowledge char:
-----------------
The ACK char Hex 06 is sent when a block sent matches the block count,
CKSM bytes match, inverted and uninverted block # bytes match and receiver
can do his I/O correctly. This means that if everything is OK, the receiver
sends ACK to ACKnowledge the block or EOT or CAN.
If the receiver cannot continue receiving, for any reason what so ever, he
sends the CAN char and CANcels the transmission.

So what does the receiver do?
-----------------------------
The receiver receives the block, checks for the above errors, and
ACKnowledges or Negatively AcKnowledges the transmission. Also the
receiving program should take notice that the sender does not CANcel the
transmission or that his side is OK. If his side is not able of receiving
the information, he must CANcel the transmissio.

XModem CRC:
-----------
The CRC XModem protocol is almost identical. It has only two changes:
1) The ability to send long blocks of 1024 bytes, by using the STX char as
   beginning-of-block sign. [STX = CHR$(2)].
2) The CKSM is not a single byte but two bytes, calculated by a polynomial
   function.
The CRC XModem is recognized by the receiver's sending "C" [CHR$(67)]
instead of NAK as sign of "ready-to-receive".

A diagram of an XModem checksum protocol session (including an error):
----------------------------------------------------------------------

 SENDER                                      RECEIVER
--------                                    ----------
                                               NAK - to signal ready.
SOH 01 FE Data[128] CKSM
                                               ACK - to ACKnowledge.
SOH 02 FD Data[128] CKSM
                                               NAK - block wrong.
SOH 02 FD Data[128] CKSM
                                               ACK
SOH 03 FC Data[128] CKSM
                                               ACK
SOH 04 FB Data[100]+[28 nulls] CKSM
                                               ACK
EOT
                                               ACK
--------------------------------------------------------------------------
CANcel char on the sender's side can come instead of the SOH and be ACK'd.
On the receiver's side, it can come instead of the ACK and be ACK'd by the
sender.

/************************************************************************\
*                                                                        *
*   This has been another presentation of Lightning House Software Co.   *
*                                                                        *
\************************************************************************/