Stuart Baker Software offers high quality consulting services and products to users of IBM PCs and compatibles (DOS and Windows)
    as well as Interdata, Perkin-Elmer and Concurrent Computer Corporation 3200 series machines (OS/32).

Kermit and Xmodem


Kermit and Xmodem -- A Comparison

by Stuart Baker
Stuart Baker Software
9370 Golondrina Drive
La Mesa, CA 91941-5654
(619) 466-8811

This article compares the Kermit and Xmodem file transfer protocols. For those of you that are not familiar with Kermit and Xmodem let me define what they are. Both Kermit and Xmodem provide the means of transferring data between computer systems in an error free manner. These protocols transmit data using standard serial telecommunications links. They work over dedicated links, line drivers or modems. Data to be transferred is placed into packets and transmitted with a check sum. When a packet is received, the check sum is computed and compared with the received value. If the check sums do not match, a NAK (negative acknowledge) is sent to the sending system, asking for re-transmission of the packet. This procedure insures that when the data reaches the remote system it will not contain errors.

Ward Christensen originally developed the Xmodem protocol to allow error free data transfer between CP/M computer systems. The first implementation employed a simple 8-bit check sum. Since it was possible to sneak bad data past this simple check sum method, an enhancement to the protocol incorporated the use of CRC16 to form the check sum. This sophisticated check sum method makes the protocol very reliable.

Since the Xmodem protocol was designed to efficiently transfer binary data between CP/M microcomputer systems, its design does not always work well on other computer systems. The problems arise from the fact that the protocol requires 8-bit communications links and it uses all data combinations between hex 00 to FF. This works fine on most point to point links, but can cause problems over networks and data concentrators that reserve some of the characters for their own use. For this reason, the Xmodem protocol was not implemented on many mainframe computer systems. The protocol is implemented on most PC platforms as well as many minicomputers, including OS/32.

The Kermit protocol was designed by the Systems Group of the Columbia University Center for Computing Activities. Yes, the protocol was named after Kermit the Frog, star of the television series THE MUPPET SHOW. From the beginning, the design took into account the restrictions placed upon serial communications by mainframe computer systems. The resultant design is general enough to fit almost any system. The protocol is capable of transferring 8-bit data over 7-bit communications lines. The only control characters typically used by the protocol are SOH (Start of Header) and CR (Carriage Return). Both of these characters are passed transparently by virtually every serial communications link. Because the design works well on mainframe systems, Kermit rapidly became available on almost all computer platforms, including OS/32.

Now that we have covered the basics, lets make a more detailed comparison. Both protocols transfer data in packets. Xmodem CRC uses 133 byte fixed length packets. The drawback to fixed length packets is determining the exact end of the real data. Xmodem uses Ctrl-Z to flag the end of text mode transfers. On the other hand, binary mode is rounded up to the next 128 byte boundary because all characters are treated as data. Kermit uses variable length packets typically terminated with a CR. In Kermit you always receive the correct number of characters for both text and binary file transfers.

Xmodem has one packet type -- data. Responses are single characters -- ACK, NAK and CAN. In every day use this works quite well. In extremely noisy line conditions it is possible to have the transfer fail. In comparison, Kermit has ten packet types. Responses are complete packets with check sums. The Kermit implementation is more robust, with virtually no chance of line noise changing the meaning of a response. In addition, the ACK and NAK packets include a reference to packet number. This feature allows implementation of protocol enhancements such as sliding windows.

Xmodem sends or receives one file each time the program is run. If you have a large number of files to transfer a lot of work is needed to automate the transfer. Kermit on the other hand can send multiple files in one group. The group to be transferred is defined using wildcards or select files. During a group transfer, the user can take action that causes the current file to be skipped or the entire transfer to be terminated.

Xmodem handles file name collision by aborting the transfer, replacing or appending to the file. Kermit has a sophisticated mechanism for renaming upon file name collision. In addition, since file names on remote systems may not follow the naming convention of your system, the protocol must handle file name conversion. In addition to rename, you may also select file replacement or append modes.

Xmodem sends an exact image of the data and requires an 8-bit line to transfer 7-bit data. Since the packet numbers and check sums can be any character from hex 00 through FF, conflicts can exist with many systems. Kermit converts control characters to printing ASCII characters to allow them to pass through systems that reserve control characters for their own use. This prefixing mechanism adds overhead to the protocol, generally making data transfer slower than Xmodem. Kermit makes up for this slowdown by incorporating repeat character prefixing and extended packets. With these additions the Kermit protocol runs anywhere from slightly slower to up to three times faster, depending upon the data mix.

The Xmodem protocol has undergone only one design change since its original release, the addition of CRC. Several variations of the protocol have been created, using the name Ymodem, Zmodem, etc., but they are not upward compatible with the original protocol. Kermit on the other hand has undergone many extensions to the original design, all upward compatible with the original specification. Because of this, all Kermits work with each other, but not all Kermits are created equal! A full implementation of the Kermit specification supports local and remote operation, wildcard send, server mode, server control, local file management, extended packets, attribute packets and sliding windows to name a few. At this point a Kermit implementation exists for OS/32 that supports all of the protocol extensions except for attribute packets and sliding windows.

In looking back at the above comparison, it appears that Kermit is definitely the protocol of choice. The Kermit protocol is much more complex to implement than Xmodem, requiring more than double the lines of code. But, the end result is a flexible and easy to use protocol that allows file transfers to almost all computer platforms. My congratulations goes out to the Systems Group of the Columbia University Center for Computing Activities. They have created a very comprehensive and well thought out protocol. Since they have maintained control of the protocol, the implementations on the different systems have maintained a high degree of compatibility. In my testing I have not found a single Kermit that was not compatible with my implementation.

Well that about does it for this issue. I hope that the information in this article will clarify the differences between the Kermit and Xmodem file transfer protocols. Having access to protocols of this type make sending data between OS/32 and virtually any other computer systems a snap.

Return to Index
Article Copyright 1991 Stuart J. Baker

This SBSW.COM page has been optimized for printing.
Web Content Copyright © 1997 - 2010 Stuart Baker Software. All rights reserved.

Please use our Feedback form to submit questions or comments about this web site.
Web Content Copyright © 1997 - 2010 Stuart Baker Software. All rights reserved.
This site was last modified: Wednesday, December 29, 2010