The Kermit Protocol

The Kermit protocol was developed in 1981 by Frank Da Cruz and Bill Catching at Columbia University. The purpose of developing this protocol was to overcome some compatibility problems that existed in the XMODEM and the YMODEM protocols. Unlike XMODEM and YMODEM, the Kermit protocol can work on different platforms and allow file transfers and data exchanges between two devices on different operating systems. Another special point of the Kermit protocol is that it uses a packet, not a single character, as a handshaking signal for communications between the transmitter and the receiver.

Compared with the XMODEM and YMODEM protocols, Kermit has the following advantages: • Kermit is a packet-oriented protocol, which means that all its handshaking signals are

composed of packets. Unlike XMODEM and YMODEM, which each utilize a single character as the handshaking signal, Kermit uses packets to communicate between the sender and the receiver. This prevents confusion that might otherwise be introduced by the similarity between the data characters and handshaking characters, such as XON/ XOFF, C, G, EOT, and so on.

• The operation sequence of the Kermit protocol is similar to that of the XMODEM protocol, but Kermit can transfer multiple files at a time. This is different than XMODEM, which can transfer only one file at a time.

• The packet’s length can be modified based on each batch transfer requirement, and even the entire packet can be empty.

• The packet’s contents can be extendible, which means that some new features can be added into a packet, and this addition will not affect the previous definition of the packet. The batch transfer process in the Kermit protocol is similar to that in XMODEM. The beginning of the file transfer is triggered by the receiver, which sends an initial packet that includes a NAK character to the transmitter. As soon as the transmitter receives this starting packet, it sends out the whole block of data (the packet). When the receiver receives the data packet, it sends an ACK packet to request that the transmitter send the next block of data (the packet), or if errors are FIGURE 1.47 The block diagram of the YMODEM-G protocol.

(a) Transmitter (b) Receiver

Receive G ? N

Send all blocks

Receive Feedback ? N _Y Send an EOT All Files Transmitted ? N

Send a Null File Name

Receive EOT ? N

Send a G

Send Feedback Receiving all blocks

All Files Transmitted ? N

Receive a Null File Name Y Any Error ? N Y Send CANs Receive CAN? Y N Start End End Start Y Y

detected, the receiver sends a NAK packet asking that the transmitter resend the previous packet. Figure 1.48 shows a typical Kermit packet format.

The explanation for each field is listed here:

• MARK: This is the start mark of the packet, which is equivalent to an SOH byte. • LEN: This indicates the total number of bytes in the packet. This number does not

include the LEN itself or the MARK byte.

• SEQ: This is a modulo-64 sequence number. The sequence number starts with the first packet, the S packet. The range is between 0 and 63.

• TYPE: This is an ASCII character used to indicate which packet type is transmitted. The Kermit protocol has the following packet types:

A—Attribute packet B—EOT packet D—Data packet E—Error packet F—File header packet N—NAK packet

S—Send initiate or start packet T—Reserved and not currently used X—Display text on screen packet Y—ACK packet

Z—EOF packet

• DATA: This field contains the real data values. The length and contents of the field vary according to the different packet types, and in some packet types, nothing exists in this field.

• CHECK: This is a checksum value used for error checking during packet transmission. Both the LEN and the SEQ fields are covered by the checksum calculations, but the MARK field is excluded. The default checksum value is a single byte, but it can be extended to double bytes or even three bytes, or 16-bit CRC values.

More detailed information for each of the packet types is listed here:

• S packet: The purpose of this packet is to inform the receiver that the transmitter will

send some communication parameters with the packet. The sequence number of the S packet is 0. Its DATA field contains a total of 10 subfields, and each has a different functionality, such as the maximum packet size the receiver can receive, the maximum number of seconds to wait, the special character used to terminate a packet, and so on. • Y packet: This packet is equivalent to an ACK packet; it is used by the receiver to

indicate to the transmitter that a special packet, such as an S packet, has been received. This packet generally contains the following fields:

SEQ (sequence number) LEN (length of bytes) CHECK

DATA

FIGURE 1.48 A typical Kermit packet format. LEN

The default DATA field in this Y-type packet is an empty field, but you can place feedback information in the field.

• F packet: This packet contains the name of the file to be transmitted. The file name is

generally limited to digits or uppercase characters.

• N packet: This packet is equivalent to a NAK packet. When transmission errors are

detected or a bad packet is received, the receiver will send a NAK packet back to the transmitter to ask that it resend the packet. This packet contains the following fields: SEQ

LEN CHECK DATA

• The DATA field is generally empty.

• D packet: This is a DATA packet, and its DATA field contains the actual data to be

transmitted.

• B packet: When the transmitter finishes all file transmissions, it sends a B (EOT) packet

to the receiver to inform the latter that the transmission has been completed. The receiver can then feed back the transmitter with an ACK packet to indicate that the B packet is successfully received. Another packet the receiver can send is a NAK packet, which means that some errors occurred during the previous file transmission and that the receiver needs the transmitter to resend the packet.

• Z packet: When the transmitter finishes one file transmission, it sends a Z (EOF) packet

to inform the receiver that the file has been transmitted. The receiver can respond to the transmitter with an ACK packet to indicate that the Z packet has been successfully received. Another packet the receiver can send is a NAK packet, which means that some errors occurred during the previous file transmission and that the receiver needs the transmitter to resend the packet.

• E packet: The E packet is used to transmit an error message from either one of the

devices. This packet is sent if an error occurs during the packet transmission in either direction.

• A packet: This packet is used to transmit additional parameters, or attributes, for a file

to be transmitted. These additional attributes are used to describe the properties of the file, such as its size, its contents, the date and time when it was created, the path where it is located, and any access information.

Relatively speaking, Kermit is a general-purpose protocol. This means that it can be utilized on any operating system with any platform. Because of its versatility, this protocol is more complicated in design and implementation than some of the other protocols discussed in this section. To determine which protocol is most suitable for your application, you need to consider the tradeoffs you’ll make with each. For example, if your file-transferring tasks are small, and only a single file is usually transmitted, XMODEM-CRC is a good candidate. On the other hand, if you need to transfer numerous files of different sizes, the YMODEM-1K or the ZMODEM format would probably be a better choice. The Kermit protocol would be the most appropriate selection if you plan to transmit numerous files among different operating systems.