120 lines
5.9 KiB
Plaintext
120 lines
5.9 KiB
Plaintext
|
+-------------------------------------------------------------------------+
|
||
|
! !
|
||
|
! 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. *
|
||
|
* *
|
||
|
\************************************************************************/
|