XMODEM

From Wikipedia, the free encyclopedia

XMODEM is a simple file transfer protocol developed as a quick hack by Ward Christensen for use in his 1977 MODEM.ASM terminal program. XMODEM became extremely popular in the early bulletin board system (BBS) market, largely because it was so simple to implement. It was also fairly inefficient, and as modem speeds increased this problem led to the development of a number of modified versions of XMODEM to improve performance or address other problems with the protocol. Chuck Forsberg collected a number of these into his YMODEM protocol, but poor implementation led to a further fracturing. His later ZMODEM protocol was so superior that it led to the demise of all of these XMODEM derivatives in the early 1990s.

Contents 1 XMODEM 1.1 Packet structure 1.2 Transfer details 1.3 Minor problems 1.4 More major problems 2 Batch Transfers 2.1 MODEM7 2.2 TeLink 3 XMODEM-CRC 4 Higher throughput 4.1 SEAlink 4.2 XMODEM-1K 5 References

[edit] XMODEM

XMODEM, like most file transfer protocols, breaks up the original data into a series of packets that are sent to the receiver, along with additional information allowing the receiver to determine whether that packet was correctly received.

[edit] Packet structure

The original XMODEM used a 128-byte data packet, the basic block size used on CP/M floppy disks. The packet was prefixed by a simple 3-byte header containing a SOH character, a "block number" from 0-255, and the "inverse" block number—255 minus the block number.

The packet was also suffixed with a single-byte checksum of the data bytes. The checksum was calculated by adding each byte of data together. Each time the summation exceeded 255, the sum started over at zero (see Modulo operation). For instance, if the data bytes were 130 + 130, the resulting checksum would equal 4 using this method.

The complete packet was thus 132 bytes long, containing 128 bytes of data, for a total throughput efficiency of about 97%.

The file was marked "complete" with a EOT character sent after the last block. This packet was not in a block, but sent alone as a single character. The last packet being padded out to 128 bytes if needed. The padding was originally the SUB character (called CPMEOF in the standard) which has value of 26 decimal. But the padding is actually allowed to contain anything according to the standard. This is necessary because the length of the file is not transmitted. If the receiver has no way how to determine that the file has ended, he's going to continue interpreting the padding. So the sender constructs the padding in a way that it's harmless for the used interpretation.

[edit] Transfer details

Files were transferred one packet at a time. When received, the packet's checksum was calculated by the receiver and compared to the one received from the sender at the end of the packet. If the two matched, the receiver sent an ACK message back to the sender, which then sent the next packet in sequence. If there was a problem with the checksum, the receiver instead sent a NAK. The sender would try ten resends before giving up on the transfer.

A NAK was also sent if the receiver did not receive a valid packet within ten seconds while still expecting data due to the lack of a EOT character. A one-second timeout was also used within a packet, guarding against dropped connections in mid-packet.

The block numbers were also examined in a simple way to check for errors. After receiving a packet successfully, the next packet should have a one-higher number. If it instead received the same block number this was not considered serious, it was implied that the ACK had not been received by the sender, which had then re-sent the packet.

Transfers were sender-driven, the receiver acting passively on data sent to it. However, the transfer was actually started by the receiver sending a single NAK. This was a side-effect of the way the user interacted with the sending machine, generally by navigating to the requested file, asking the sender to transfer it, then using a command in their local software to start receiving. Since the delay until the user could invoke the command was unknown, XMODEM instead made the receiver trigger the transfer when it was ready.

[edit] Minor problems

XMODEM was written for CP/M machines, and bears several marks of that operating system. Notably, files on CP/M were always multiples of 128 bytes, and their end was marked within a block with the EOT character. These characteristics were transplanted directly into XMODEM. However, other operating systems did not feature either of these peculiarities, and the widespread introduction of MS-DOS in the early 1980s led to XMODEM having to be updated to notice either a EOT or EOF as the end-of-file marker.

For some time it was suggested that sending a CAN character instead of an ACK or NAK should be supported in order to easily abort the transfer from the receiving end. Likewise, a CAN received in place of the SOH indicated the sender wished to cancel the transfer. However, this character could be easily "created" via simple noise-related errors of what was meant to be an ACK or NAK. A double-CAN was proposed to avoid this problem, but it is not clear if this was widely implemented.

[edit] More major problems

XMODEM was designed for simplicity, without much knowledge of other file transfer protocols – which were fairly rare anyway. Due to its simplicity, there were a number of very basic errors that could cause a transfer to fail, or worse, result in an incorrect file which went unnoticed by the protocol. Most of this was due to the use of a simple checksum for error correction, which is susceptible to missing errors in the data if two bits are reversed, which can happen with a suitably short burst of noise. Additionally, similar damage to the header or checksum could lead to a failed transfer in cases where the data itself was undamaged.

Many authors introduced extensions to XMODEM to address these and other problems. Many asked for these extensions to be included as part of a new XMODEM standard. However, Ward Christensen refused to do this, as it was precisely the lack of these features, and the associated coding needed to support them, that led to XMODEM's widespread use. As he explained:

It was a quick hack I threw together, very unplanned (like everything I do), to satisfy a personal need to communicate with some other people. ONLY the fact that it was done in 8/77, and that I put it in the public domain immediately, made it become the standard that it is...

...People who suggest I make SIGNIFICANT changes to the protocol, such as 'full duplex', 'multiple outstanding blocks', 'multiple destinations', etc etc don't understand that the incredible simplicity of the protocol is one of the reasons it survived.

[edit] Batch Transfers

Another problem with XMODEM was that it required the transfer to be user-driven. Typically this meant the user would navigate on the sender's system to select the file they wanted, and then invoke the transfer from their end using a command in their terminal emulator.

For automated transfers between two sites, a number of add-ons to the XMODEM protocol were implemented over time. These generally assumed the sender would continue sending file after file, with the receiver attempting to trigger the next file by sending a NAK as normal at the start of a transfer. When the NAK's timed out, it could be assumed that either there were no more files, or the link was broken anyway.

[edit] MODEM7

MODEM7 was the first known extension of the XMODEM protocol. An XMODEM file transfer starts with the receiver sending a single NAK character to the sender, which then starts sending packets of 128-bytes of data prefixed with a SOH. MODEM7 changed this behaviour only slightly, by sending the filename, in 8.3 format, before the first data packet. For a non-aware XMODEM implementation this data would simply be ignored while it waited for the SOH to arrive. With "aware" software, the file could be saved with that name. Transfers could continue with another NAK, each file being saved under the name being sent to the receiver.

[edit] TeLink

MODEM7 sent the filename as normal text, which meant it could be corrupted by the same problems that XMODEM was attempting to avoid. This led to the introduction of TeLink by Tom Jennings, author of the original FidoNet mailers.

TeLink avoided MODEM7's problems by standardizing a new "zero packet" containing information about the original file. This included the file's name, size, and timestamp, which were placed in a regular 128 byte XMODEM block. Whereas a normal XMODEM transfer would start with the sender sending "block 1", the TeLink header packet was labeled "block 0".

Again, a normal XMODEM implementation would simply discard the packet, the assumption being that the packet number had been corrupted. But this led to a potential time delay if the packet were discarded, as the sender could not be sure it was being NAK'ed because it did not understand the "block 0", or because the was a transmission error. However, TeLink was generally limited to FidoNet software, which demanded it, so it was safe to assume the receiver implemented it as well.

The basic "block 0" system became a standard in the FidoNet community, and was re-used by a number of future protocols as a result.

[edit] XMODEM-CRC

The checksum used in the original protocol was extremely simple, and errors within the packet could go unnoticed. This led to the introduction of XMODEM-CRC by John Mahr, which used a 16-bit CRC in place of the 8-bit checksum. CRC's encode not only the data in the packet, but its location as well, allowing it to notice the bit-replacement errors that a checksum would miss. Statistically, this made the chance of detecting an error less than 16 bytes long 99.9969%, and even higher for longer data.

XMODEM-CRC was designed to be backwardly compatible with XMODEM. To do this, the receiver simply sent a C character instead of a NAK to start the transfer. If the sender responded by sending a packet, it was assumed the sender "knew" XMODEM-CRC, and the receiver continued sending C's. If no packet was forthcoming, the receiver assumed the sender did not know the protocol, and sent an NAK to start a "traditional" XMODEM transfer.

Unfortunately this attempt at backward compatibility had a downside. Since it was possible that the initial C character would be lost or corrupted, it could not be assumed that the receiver did not support XMODEM-CRC if the first attempt to trigger the transfer failed. The receiver thus tried to start the transfer three times with C, waiting three seconds between each attempt. This meant that if the user selected XMODEM-CRC while attempting to talk to any XMODEM, as it was intended, there was a potential 10 second delay before the transfer started.

To avoid the delay, the sender and receiver would generally list XMODEM-CRC separately from XMODEM, allowing the user to select "basic" XMODEM if the sender didn't explicitly list it. Ironically, any software that did support -CRC in their basic XMODEM transfer, as it was intended, surreptitiously suggested the user should not attempt to use -CRC. To the average user, XMODEM-CRC was essentially a "second protocol", and treated as such.

[edit] Higher throughput

Since the XMODEM protocol required the sender to stop and wait for an ACK or NAK message from the receiver, it tended to be quite slow. In the era of 300 bit/s modems, the entire 132-byte packet required just over 3.5 seconds to send (132 bytes * 8 bits per byte / 300 bits per second). If it then took 0.2 seconds for the receiver's ACK to make it back to the sender and the next packet to start hitting the receiver (0.1 seconds in both directions), the overall time for one packet would be 3.7 seconds, just over 92% throughput.

As modem speeds increase, the fixed delay needed to send the ACK/NAK grows in proportion to time needed to send the packet. For instance, at 2400 bit/s the packets took only 0.44 seconds to send, so if the ACK/NAK still took 0.2 seconds to make it back (this is latency, not throughput), the throughput has fallen to under 60%. At 9600 bit/s it is under 30% – more time is spent waiting for the reply than is needed to send the packet.

A number of new versions of XMODEM were introduced in order to address these problems. Like earlier extensions, these versions tended to be backward-compatible with the original XMODEM, and like those extensions, this led to a further fracturing of the XMODEM landscape in the user's terminal emulator. In the end, dozens of versions of XMODEM would emerge.

[edit] SEAlink

One of the first "third party" mailers for the FidoNet system was SEAdog, written by the same author as the then-popular .arc data compression format. SEAdog included a wide variety of improvements, including SEAlink, an improved transfer protocol.

SEAlink used a method known as sliding windows to avoid the inter-packet delay. To do this, the protocol did not wait for the ACK/NAK to arrive, and immediately moved onto the next packet. It was only after some number of packets had been sent, the "window", that the protocol would stop and wait.

In order for this to work, SEAlink needed to known which packet the receiver was ACK/NAKing, which it did by appending the packet number to the ACK or NAK character.

[edit] XMODEM-1K

Another way to solve the throughput problem is to increase the packet size. Although the fundamental problem of latency remains, the speed at which it becomes a problem is higher. XMODEM-1K with 1024-byte packets was the most popular such solution. In this case the througput at 9600 bit/s is 81%, given the same assumptions as above.

XMODEM-1K was an expanded version of XMODEM-CRC, which indicated the longer block size in the sender by starting a packet with the STX character instead of SOH. Like other backward-compatible XMODEM extensions,

XMODEM-1K was actually one of the many improvements to XMODEM introduced by Chuck Forsberg in his YMODEM protocol. However, Forsberg suggested that the various improvements were optional, expecting software authors to implement as many of them as possible. Instead they generally implemented the bare minimum, leading to a profusion of semi-compatible implementations, and eventually, the splitting out of the name "YMODEM" into "XMODEM-1k" and a variety of YMODEMs.

[edit] References

• XMODEM/YMODEM Protocol Reference, Chuck Forsberg