XMODEM is a simple file transfer protocol developed as a quick hack by Ward Christensen for use in his 1977 MODEM.ASM terminal program.
Keith Petersen made a minor update to always turn on "quiet mode", and called the result XMODEM.
XMODEM became extremely popular in the early bulletin board system (BBS) market, largely because it was simple to implement.
If a
Although XMODEM was robust enough for a journalist in 1982 to transmit stories from Pakistan to the United States with an Osborne 1 and acoustic coupler over poor-quality telephone lines,[6] the protocol had several flaws.
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
For some time it was suggested that sending a
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.
Additionally, similar damage to the header or checksum could lead to a failed transfer in cases where the data itself was undamaged.
However, Ward Christensen refused to do this, as it was precisely the lack of these features, and the associated coding needed to support them, which led to XMODEM's widespread use.
For automated transfers between two sites, a number of add-ons to the XMODEM protocol were implemented over time.
[8] The basic "block 0" system became a standard in the FidoNet community, and was re-used by a number of future protocols like SEAlink and YMODEM.
[4] CRCs 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.
If no packet was forthcoming, the receiver assumed the sender did not know the protocol, and sent an
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.
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.
[8] Since the XMODEM protocol required the sender to stop and wait for an
The time for the
As modem speeds increased, the fixed delay grew in proportion to time needed to send the packet.
Finally, in the case of an error that required a resend, it was sometimes difficult to know whether a SOH was a packet indicator or more noise.
[11] One change was to escape a small set of control characters: DLE, XON, XOFF and SYN.
In theory, this meant the packet might be as long as 264 bytes if it originally consisted entirely of characters that required escaping.
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.
This suppressed ACKs for packets that were successfully transferred, in effect making the window of infinite size.
XMODEM-1K was an expanded version of XMODEM-CRC, which indicated the longer block size in the sender by starting a packet with the
NMODEM was implemented as a separate program, written in Turbo Pascal 5.0 for the IBM PC compatible family of computers.
[13][14] Over reliable (error-free) connections, it is possible to eliminate latency by "pre-acknowledging" the packets, a technique known more generally as "protocol spoofing".
The modems also suppress the ACK being sent by the XMODEM software at the far end, thereby freeing up the low-speed return channel.
In SEAlink, the receiver stops sending the ACK entirely, and the sender changes its behavior to not expect them.