Kermit,xmodem,ymodem,zmodem Transport Protocol Summary

Source: Kermit,xmodem,ymodem,zmodem Transport Protocol Summary

Kermit protocol

Message format:

1.MARK, starting Mark Start_char, for 0x01 (CTRIL-A);

2.LEN, the length of the remainder of the message, the value range 0~94, the maximum length of the message 96, the length does not include newline characters or tabs;

3.SEQ, packet number, modulo 64,;

4.type,k_state Packet Type

Y

valign= "Top" width= "217" >

ACK Message (cannot convert encoding)

NAK, not received

Error

TD valign= "Top" width= " valign= "Top" width= "217" > valign= width= "Top" 217 "" >

D	Data message
N
S	Send initialization message
B	Transfer end
F	File header
Z	End of file
E
q,t	Reserved

The NAK package is used to indicate that the waiting packet is not received properly, and that it does not provide other information, such as a service that does not provide the request. Its data field is always empty. The t message is used for internal Kermit program description timeouts.

5. data,0~31,127 These 33 control characters need to be converted, preceded by ' # ', 0~31 with 64,127 minus 64 processing. The sequence of prefixes is not dispersed in different packages. The prefix character is also contained within the count. Except for S,I,A messages and their responses, they cannot be encoded.

6. Check, if S is the arithmetic sum of the whole paper character, just check the sum of the 0~5 bit.

This is the basic default block checksum, and all Kermit must be implemented.

Kermit message sending process

1. The sender first sends an initialization message s (starting with 0x01), determines the length of the message, time-out, etc.;-->

<--Receiver Returns a confirmation message y, storing its own parameters in the message data segment

2. Send the file header message F, the data segment contains the file name--(if you send multiple files, repeat this step can be)

<--returns ACK, data segment can contain no data

3. Start sending the contents of the file, data packet D, not within the range of printable ASCII code, need to be replaced in advance to the equivalent printable characters, each data message will receive an ACK.

4. After the file data is sent, the sender sends the end of the file Z, receiver pays after receiving confirmation.

5. When no files need to be sent, transmit end message B is sent, the ACK is received, and the connection is closed, and the physical connection remains

Each message is numbered and 0~63.

XMODEM

Simple and general, transmission information Unit is "packet =128b", transmission speed is slow, suitable for the poor quality of the telephone line in the case of the use.

Xmodem is one of the most widely used file transfer protocols. The original XMODEM protocol uses 128-byte packets and a simple "checksum" error detection method. Subsequent versions of XMODEM-CRC use a more secure cyclic redundancy check (CRC) Error detection method. The XMODEM protocol always attempts to use the CRC first. If the sender does not respond to a CRC request, the receiver is transferred to the checksum mode and continues its request transfer.

1. What is the Xmodem protocol?

Xmodem protocol is a kind of asynchronous file Transfer protocol widely used in serial communication. It is divided into standard Xmodem and 1k-xmodem two, which transmits data in 128-byte chunks, the latter byte block is 1k or 1024 bytes, and each block uses a checksum procedure for error detection. The receiver sends a confirmation byte (ACK) to the sender when the receiver's checksum about a block is the same as the checksum of the sender in the validation process. Because Xmodem needs to recognize each block, this results in performance degradation, especially when the delay is longer, and the protocol appears to be less efficient.

In addition to Xmodem, there are ymodem,zmodem agreements. Their protocol content is similar to Xmodem, except that Ymodem allows batch file transfer and is more efficient;Zmodem is the improved Xmodem, which only needs to be re-sent to the damaged block. Other correct blocks do not need to send acknowledgement bytes. Reduced traffic.

2. XMODEM protocol-related control characters

SOH 0x01

STX 0x02

EOT 0x04

ACK 0x06

NAK 0x15

CAN 0x18

Ctrlz 0x1A

3. Standard XMODEM Protocol (contains 128 bytes of data per data) frame format

2-1

SOH

Message packet number

The complement of the message pack ordinal

Data segment

Checksum

4. 1k-xmodem (contains 1024 bytes of data per data) frame format

2-2

STX

Message packet number

The complement of the message pack ordinal

Data segment

Checksum

5. Packet description

For standard XMODEM protocols, if the transmitted file is not an integer multiple of 128, then the valid content of the last packet is certainly less than the frame length, and the insufficient part needs to be populated with ctrl-z (0x1A). Someone here might ask, if I'm transmitting a. bin file generated by the bootloader project, what happens to the MCU after it receives the 0x1a word inode? In fact, if the transmission is a text file, then the receiver is very easy to recognize the content received, because Ctrl-z is not the first 128 ASCII, not a universal visible character, if it is a binary file, the MCU will not actually use it as code to execute. Even Excel files, etc., will not read extra padding characters because there are some structures within it that represent the length of each field. Otherwise the xmodem is too weak. For 1k-xmodem, ditto.

6. How do I start a transfer?

The transmission is initiated by the receiver by sending a "C" or Nak to the sender (note that the Nak mentioned here is used to initiate the transfer.) Below we see a mechanism that NAK can also be used to generate retransmission of data. The receiver sends a NAK signal to indicate that the receiver intends to use accumulation and verification; the sending character "C" indicates that the receiver intends to use CRC check (Xmodem source code, the source speaks louder than words).

7. Transfer process

When the first "C" or Nak sent by the receiver arrives at the sender, the sender thinks it can send the first packet, and the transmission has started. The sender should then add the data to each 128 bytes of data with the header, the package number, the complement of the package, plus the checksum at the end, packaged into a frame format for delivery. When the sender sends the first packet, it waits for the acknowledgment byte ack of the receiver, receives the ACK acknowledgement from the receiving party, considers that the packet is properly received by the receiver, and the receiver requests the sender to continue sending the next packet, if the sender receives a NAK from the receiver (here, Nak is used to tell the sender to retransmit, is not used to start the transfer) bytes, it means that the receiver requests to resend the packet just now, and if the sender receives the can bytes from the receiver, the receiver requests that the transmission be stopped unconditionally.

8. How do I end the transfer?

If the sender transmits all the data properly, it needs to end the transmission, and the normal end requires the sender to send EoT bytes to the receiver. The receiver returns an ACK for confirmation. Of course, the receiver can also force stop transmission, when the receiver sends can bytes to the sender, indicating that the receiver wants to stop the transmission unconditionally, the sender receives can, do not need to send EOT confirmation (because the receiver has not wanted to ignore it, hehe).

9. Special handling

Although the packet is an SOH to mark the beginning of an information packet, but in the SOH position if the occurrence of eot means the end of the data transmission, there is no information sent over. The receiver should first confirm the integrity of the packet ordinal, by filling the packet ordinal, and then the complement of the packet ordinal or, the result is 0 is correct, the result is not 0 send Nak request retransmission.

The receiver confirms that the packet sequence number is correct, and then checks to see if the expected ordinal. If you are not expecting a packet sequence number that indicates a critical error, you should send a CAN to abort the transmission.

If the packet sequence of the received packet is the same as the previous packet, the receiver ignores the duplicate packet, sends an ACK to the sender, and prepares to receive the next packet.

After the receiver confirms the integrity of the packet sequence and is expected to be correct, only the 128-byte data segment is mathematically and checked, and the result is compared to the last byte (arithmetic checksum) in the frame, sending the same ACK, and sending the NAK differently.

10. Description of the Checksum

The XMODEM protocol supports 2 checksums, which are cumulative and with CRC checksum. When the receiver starts the transfer at the beginning, it sends a nak, indicating that it wants to be verified in addition and in a way.

When the receiver starts the transmission at first, it sends the character "C", indicating that it wants to check it in CRC mode.

Some people may ask, how does the receiver want to verify that the sender has to cooperate, the sender must all support the cumulative and checksum CRC checksum? In fact, Xmodem requires support for CRC must also support the cumulative sum, if the sender only support the cumulative sum, and the receiver with the character "C" to start, then as long as the sender regardless of it, when the receiver continues to send "C", after three times did not receive the answer, will automatically change to send NAK, Since it has been understood that the sender may not support CRC verification, the receiver now changes to accumulate and verify the sender communication. The sender receives the NAK and sends a packet response.

Ymodem

Evolved from Xmodem, high efficiency and reliability, package =128*8b; a single transmission can send or receive several files.

XMODEM1K is essentially a packet of Xmodem crc1k (1024 bytes). In some systems, it can also be called Ymodem. Some communication software programs, known as the 1.x version of ProComm, also refer to xmodem-1k as Ymodem, but are no longer called xmodem-1k in the 2.0 version of ProComm.

Ymodem-g:ymodem-g is a variant of Ymodem. It is designed to be used for modems that support error control. The protocol does not provide software correction or recovery, but is expected to provide services to the modem. This is a streaming protocol that sends and receives 1K of packets on a continuous stream of data, explicitly stopping them. After each block is sent, it does not wait for a positive acknowledgment, but instead sends the block quickly and continuously. If any block transfer fails, this transfer will fail to exit.

The file transfer process opens:

(1) Open is transmitted by the receiver, it sends a capital letter C to turn on the transmission. Then enter the wait (SOH) state, and if there is no response, it will time out.

(2) The sender is at the beginning of the wait process, waiting for C. After receiving C, send (SOH) packet start signal, send serial number (00), complement (FF), "filename", "Space" "File Size" "Remove ordinal, fill 128 bytes", CRC check two bytes. Enter the wait (ACK) state.

(3) When the receiving party receives, the CRC checksum is satisfied, then the ACK is sent. The sender receives an ACK and enters the wait for a "file transfer on" signal, which re-enters the status of waiting for "C".

(4) The front receiver just received a file name, restricting the official opening of the transfer of files, Ymodem support 128 bytes and 1024 bytes a packet. 128 bytes starting with (SOH), 1024 bytes starting with (STX).

The receiver sends a "C" signal and begins preparing to receive the file. Go to the "SOH" or "STX" state.

(5) Send received "C" after sending the packet, (SOH) (01 serial number) (Fe complement) (128-bit data) (CRC check), waiting for the receiver "ACK".

(6) After the file is sent, the sender sends out a "EOT" signal, and the receiver responds with an "ACK".

Then the receiver will issue "C" again to open another transmission, if the sender will send a "full 0 packets", the receiver "ACK" after the communication officially ended.

(7) Of course, the improvement of ymodem relative to Xmodem is that after the transmission is opened again, you can send another file, that is, one transfer allows multiple files to be sent.

The symbols used

#define MODEM_SOH 0x01//Data block start character

#define MODEM_STX 0x02//1028 byte start

#define MODEM_EOT 0x04//end of File transfer

#define Modem_ack 0x06//Confirm Answer

#define MODEM_NAK 0x15//error occurred

#define Modem_can 0x18//Cancel Transfer

#define MODEM_C 0x43//Capital Letter C

CRC calculation method

In_ptr = mblock->buf; Point to the beginning of the buffer to calculate the CRC

cksum = 0; //

for (Stat=mblock->len; stat>0; stat--)//len is the length to be computed

{

Cksum = cksum^ (int) (*in_ptr++) << 8; //

for (i=8; i!=0; i--)

{

if (Cksum & 0x8000)

Cksum = cksum << 1 ^ 0x1021;

Else

Cksum = cksum << 1;

}

}

ZMODEM

It is more efficient to send data in a continuous stream with two different types.

In the specific environment, through the multiple use of Xmodem transmission can be found, whether direct transmission, or in accordance with the online version of RZ SZ transmission, it is difficult to transfer the file correctly to the embedded device. When Zmodem is used for transmission, it is found that the transmission efficiency is very high, almost no failure.

The Zmodem protocol has two notable features: it is very effective, it provides a crash recovery mechanism similar to that of Ymodem-g, and the Zmodem protocol does not wait for a positive acknowledgment after each block is sent, but the block is sent quickly and continuously. Zmodem protocol transmission If for any reason is canceled or interrupted, after recovery, the previously transmitted information will need to be re-sent.

Original: Kitten Eating Persimmon Blog--kermit,xmodem,ymodem,zmodem Transport Protocol Summary

Kermit,xmodem,ymodem,zmodem Transport Protocol Summary (RPM)