{"history":[],"article":{"id":"306ca1fa-d607-4ee6-bdbe-50487f601f20","title":"XMODEM","slug":"xmodem","content":":::summary\n**Title:** XMODEM \n**Purpose:** file transfer protocol \n**Developer:** [Ward Christensen](https://bliptext.com/articles/ward-christensen) \n**Date:** 1977 \n**Influenced:** [YMODEM](https://bliptext.com/articles/ymodem), many others \n**Hardware:** [modems](https://bliptext.com/articles/modem) \n:::\n\n# \n**XMODEM** is a simple [file transfer](https://bliptext.com/articles/file-transfer) protocol developed as a quick [hack](https://bliptext.com/articles/hacker-hobbyist) by [Ward Christensen](https://bliptext.com/articles/ward-christensen) for use in his 1977 **MODEM.ASM** [terminal program](https://bliptext.com/articles/terminal-program).\nIt allowed users to transmit files between their computers when both sides used MODEM.\nKeith Petersen made a minor update to always turn on \"quiet mode\", and called the result XMODEM.\nXMODEM, like most file transfer protocols, breaks up the original data into a series of \"[packets](https://bliptext.com/articles/packet-information-technology)\" that are sent to the receiver, along with additional information allowing the receiver to determine whether that packet was correctly received.\nIf an error is detected, the receiver requests that the packet be re-sent.\nA string of bad packets causes the transfer to abort.\nXMODEM became extremely popular in the early [bulletin board system](https://bliptext.com/articles/bulletin-board-system) (BBS) market, largely because it was simple to implement.\nIt 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.\nChristensen believed his original XMODEM to be \"the single most modified program in computing history\".\n[Chuck Forsberg](https://bliptext.com/articles/chuck-forsberg) collected a number of common modifications into his [YMODEM](https://bliptext.com/articles/ymodem) protocol, but poor implementation led to a further fracturing before they were re-unified by his later [ZMODEM](https://bliptext.com/articles/zmodem) protocol.\nZMODEM became very popular, but never completely replaced XMODEM in the BBS market.\n\n# Packet structure\nThe original XMODEM used a 128-byte data packet, the basic block size used on [CP/M](https://bliptext.com/articles/cp-m) [floppy disks](https://bliptext.com/articles/floppy-disk).\nThe packet was prefixed by a simple 3-byte header containing a <[SOH](https://bliptext.com/articles/c0-and-c1-control-codes)> character, a \"block number\" from 1-255, and the \"inverse\" block number—255 minus the block number.\nBlock numbering starts with 1 for the first block sent, not 0.\nThe header was followed by the 128 bytes of data, and then a single-byte [checksum](https://bliptext.com/articles/checksum).\nThe checksum was the sum of all 128 data bytes in the packet [modulo](https://bliptext.com/articles/modulo-operation) 256.\nThe complete packet was thus 132 bytes long, containing 128 bytes of [payload data](https://bliptext.com/articles/payload-computing), for a total [channel efficiency](https://bliptext.com/articles/channel-efficiency) of about 97%.\nThe file was marked \"complete\" with a <[EOT](https://bliptext.com/articles/end-of-transmission-character)> character sent after the last block.\nThis character was not in a packet, but sent alone as a single byte.\nSince the file length was not sent as part of the protocol, the last packet was padded out with a \"known character\" that could be dropped.\nIn the original specification, this defaulted to _{or 26 decimal, which CP/M used as the end-of-file marker inside its own disk format.\nThe standard suggested any character could be used for padding, but there was no way for it to be changed within the protocol itself – if an implementation changed the padding character, only clients using the same implementation would correctly interpret the new padding character.\n\n# Transfer details\nFiles were transferred one packet at a time.\nWhen 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.\nIf the two matched, the receiver sent an <[ACK](https://bliptext.com/articles/acknowledge-character)> message back to the sender, which then sent the next packet in sequence.\nIf there was a problem with the checksum, the receiver instead sent a <[NAK](https://bliptext.com/articles/negative-acknowledge-character)>.\nIf a was received, the sender would re-send the packet, and continued to try several times, normally ten, before aborting the transfer.\nA 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 character.\nA seven-second timeout was also used within a packet, guarding against dropped connections in mid-packet.\nThe block numbers were also examined in a simple way to check for errors.\nAfter receiving a packet successfully, the next packet should have a one-higher number.\nIf it instead received the same block number this was not considered serious, it was implied that the had not been received by the sender, which had then re-sent the packet.\nAny other packet number signalled that packets had been lost.\nTransfers were receiver-driven; the transmitter would not send any data until an initial was sent by the receiver.\nThis was a logical outcome of the way the user interacted with the sending machine, which would be remotely located.\nThe user would navigate to the requested file on the sending machine, and then ask that machine to transfer it.\nOnce this command was issued, the user would then execute a command in their local software to start receiving.\nSince the delay between asking the remote system for the file and issuing a local command to receive was unknown, XMODEM allowed up to 90 seconds for the receiver to begin issuing requests for data packets.\n\n# Problems\nAlthough XMODEM was robust enough for a journalist in 1982 to transmit stories from Pakistan to the United States with an [Osborne 1](https://bliptext.com/articles/osborne-1) and [acoustic coupler](https://bliptext.com/articles/acoustic-coupler) over poor-quality telephone lines, the protocol had several flaws.\n\n## Minor problems\nXMODEM was written for [CP/M](https://bliptext.com/articles/cp-m) machines, and bears several marks of that [operating system](https://bliptext.com/articles/operating-system).\nNotably, files on CP/M were always multiples of 128 bytes, and their end was marked within a block with the character.\nThese characteristics were transplanted directly into XMODEM.\nHowever, other operating systems did not feature either of these peculiarities, and the widespread introduction of [MS-DOS](https://bliptext.com/articles/ms-dos) in the early 1980s led to XMODEM having to be updated to notice either a or as the end-of-file marker.\nFor some time it was suggested that sending a character instead of an or should be supported in order to easily abort the transfer from the receiving end.\nLikewise, a received in place of the indicated the sender wished to cancel the transfer.\nHowever, this character could be easily \"created\" via simple noise-related errors of what was meant to be an or .\nA double- was proposed to avoid this problem, but it is not clear if this was widely implemented.\n\n## Major problems\nXMODEM was designed for simplicity, without much knowledge of other file transfer protocols – which were fairly rare anyway.\nDue 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.\nMost 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.\nAdditionally, similar damage to the header or checksum could lead to a failed transfer in cases where the data itself was undamaged.\nMany authors introduced extensions to XMODEM to address these and other problems.\nMany asked for these extensions to be included as part of a new XMODEM standard.\nHowever, 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.\nAs he explained:\n\n# Batch transfers\nAnother problem with XMODEM was that it required the transfer to be user-driven rather than automated.\nTypically this meant the user would navigate on the sender's system to select the file they wanted, and then use a command to put that system into the \"ready to send\" mode.\nThey would then trigger the transfer from their end using a command in their terminal emulator.\nIf the user wanted to transfer another file, they would have to repeat this process again.\nFor automated transfers between two sites, a number of add-ons to the XMODEM protocol were implemented over time.\nThese generally assumed the sender would continue sending file after file, with the receiver attempting to trigger the next file by sending a as normal at the start of a transfer.\nWhen the s timed out, it could be assumed that either there were no more files, or the link was broken anyway.\n\n## MODEM7\n**MODEM7**, also known as **MODEM7** batch or **Batch XMODEM**, was the first known extension of the XMODEM protocol.\nA normal XMODEM file transfer starts with the receiver sending a single character to the sender, which then starts sending a single to indicate the start of the data, and then packets of data.\nMODEM7 changed this behavior only slightly, by sending the filename, in [8.3 filename](https://bliptext.com/articles/8-3-filename) format, before the .\nEach character was sent individually and had to be echoed by the receiver as a form of error correction.\nFor a non-aware XMODEM implementation, this data would simply be ignored while it waited for the to arrive, so the characters would not be echoed and the implementation could fall back to conventional XMODEM.\nWith \"aware\" software, the file name could be used to save the file locally.\nTransfers could continue with another, each file is saved under the name being sent to the receiver.\n[Jerry Pournelle](https://bliptext.com/articles/jerry-pournelle) in 1983 described MODEM7 as \"probably the most popular microcomputer communications program in existence\".\n\n## TeLink\nMODEM7 sent the filename as normal text, which meant it could be corrupted by the same problems that XMODEM was attempting to avoid.\nThis led to the introduction of **TeLink** by [Tom Jennings](https://bliptext.com/articles/tom-jennings), author of the original [FidoNet](https://bliptext.com/articles/fidonet) mailers.\nTeLink avoided MODEM7's problems by standardizing a new \"zero packet\" containing information about the original file.\nThis included the file's name, size, and [timestamp](https://bliptext.com/articles/timestamp), which were placed in a regular 128 byte XMODEM block.\nWhereas a normal XMODEM transfer would start with the sender sending \"block 1\" with a header, the TeLink header packet was labeled \"block 0\" and began with a.\nThe packet contained the file creation date and time, filename up to 16 characters, the file size as a 4-byte value, and the name of the program sending the file.\nA normal XMODEM implementation would simply discard the packet, the assumption being that the packet number had been corrupted.\nBut this led to a potential time delay if the packet were discarded, as the sender could not tell whether the receiver had responded with a because it did not understand the zero packet or because there was a transmission error.\nAs TeLink was normally used only by [FidoNet](https://bliptext.com/articles/fidonet) software, which demanded it as part of the [FidoNet](https://bliptext.com/articles/fidonet) standards, this did not present a real-world problem as both ends would always support this standard.\nThe basic \"block 0\" system became a standard in the FidoNet community, and was re-used by a number of future protocols like [SEAlink](https://bliptext.com/articles/sealink) and [YMODEM](https://bliptext.com/articles/ymodem).\n\n# XMODEM-CRC\nThe checksum used in the original protocol was extremely simple, and errors within the packet could go unnoticed.\nThis led to the introduction of **XMODEM-[CRC](https://bliptext.com/articles/cyclic-redundancy-check)** by John Byrns, which used a 16-bit [CRC](https://bliptext.com/articles/cyclic-redundancy-check) in place of the 8-bit checksum.\nCRCs 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.\nStatistically, this made the chance of detecting an error less than 16 bits long 99.9969%, and even higher for longer error bit strings.\nXMODEM-CRC was designed to be backwardly compatible with XMODEM.\nTo do this, the receiver sent a C (capital C) character instead of a to start the transfer.\nIf 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 to start a \"traditional\" XMODEM transfer.\nUnfortunately, this attempt at backward compatibility had a downside.\nSince 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.\nThe receiver thus tried to start the transfer three times with C, waiting three seconds between each attempt.\nThis 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.\nTo 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.\nTo the average user, XMODEM-CRC was essentially a \"second protocol\", and treated as such.\nThis was not true of FidoNet mailers, however, where CRC was defined as the standard for all TeLink transfers.\n\n# Higher throughput\nSince the XMODEM protocol required the sender to stop and wait for an or message from the receiver, it tended to be quite slow.\nIn the era of 300 bit/s modems, the entire 132-byte packet required 4.4 seconds to send (132 bytes * (8 bits per byte + 1 start bit + 1 stop bit) / 300 bits per second).\nAssuming it takes 0.2 seconds for the receiver's 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 4.6 seconds, just over 92% channel efficiency.\nThe time for the / process was a fixed function of the underlying communications network, not of the performance of the modems.\nAs modem speeds increased, the fixed delay grew in proportion to time needed to send the packet.\nFor instance, at 2400 bit/s the packets took only 0.55 seconds to send, so if the / still took 0.2 seconds to make it back to the user's machine, the efficiency has fallen to 71%.\nAt 9600 bit/s it is just under 40% – more time is spent waiting for the reply than is needed to send the packet.\nA number of new versions of XMODEM were introduced in order to address these problems.\nLike earlier extensions, these versions tended to be backward-compatible with the original XMODEM, and like those extensions, this led to further fracturing of the XMODEM landscape in the user's terminal emulator.\nIn the end, dozens of versions of XMODEM emerged.\n\n## WXModem\n**WXmodem**, short for \"Windowed Xmodem\", is a variant of XMODEM developed by Peter Boswell in 1986 for use on high-latency lines, specifically public [X.25](https://bliptext.com/articles/x-25) systems and [PC Pursuit](https://bliptext.com/articles/pc-pursuit).\nThese have latencies that are far higher than the [plain-old telephone service](https://bliptext.com/articles/plain-old-telephone-service), which leads to very poor efficiency in XMODEM.\nAdditionally, these networks often use [control characters](https://bliptext.com/articles/control-character) for [flow control](https://bliptext.com/articles/flow-control-data) and other tasks, notably [XON/XOFF](https://bliptext.com/articles/xon-xoff) will stop the data flow.\nFinally, in the case of an error that required a resend, it was sometimes difficult to know whether a was a packet indicator or more noise.\nWXmodem adapted XMODEM-CRC to address these problems.\nOne change was to escape a small set of control characters:, , and.\nThese were escaped by inserting a in front of them, and then modifying the character by XORing it with 64.\nIn theory, this meant the packet might be as long as 264 bytes if it originally consisted entirely of characters that required escaping.\nThese inserted and modified characters are not part of the CRC calculation, they are removed and converted at the receiving end before calculating the CRC.\nAdditionally, all packets were prefixed with a character, which meant the packet lead-in was , reducing the chance that a stray would be confused for a packet header in various error cases.\nAn unescaped found in the body of a packet was an error.\nThe major change in WXMODEM is the use of a [sliding window](https://bliptext.com/articles/sliding-window) to improve throughput on high-latency links.\nTo do so, the messages were followed by the packet number they were ing or ing.\nThe receiver does not have to every packet; it is allowed to any number between one and four packets.\nAn with the fourth packet sequence number is assumed to all four packets.\nAn error causes a to be sent immediately, with all packets from that number and after being re-sent.\nRequiring an every four packets makes the system work like it has a packet size of 512 bytes, but in the case of an error, typically only requires 128 bytes to be re-sent.\nMoreover, it reduces the amount of data flowing in the reverse direction by four times.\nThis is of little interest in the typical modem's [full duplex](https://bliptext.com/articles/full-duplex) operation, but is important in [half duplex](https://bliptext.com/articles/half-duplex) systems like [Telebit](https://bliptext.com/articles/telebit) models which have 19 kB speed in one direction and 75 bits/s in the return channel.\n\n## SEAlink\nOne of the first third-party mailers for the [FidoNet](https://bliptext.com/articles/fidonet) system was **SEAdog**, written by the same author as the then-popular [.arc](https://bliptext.com/articles/arc) [data compression](https://bliptext.com/articles/data-compression) format.\nSEAdog included a wide variety of improvements, including [SEAlink](https://bliptext.com/articles/sealink), an improved transfer protocol based on the same sliding window concept as WXmodem.\nIt differed from WXmodem mostly in details.\nOne difference is that SEAlink supported the \"zero packet\" introduced by TeLink, which is needed in order to operate as a drop-in replacement for TeLink in FidoNet systems where the header was expected.\ns and s were extended to three-byte \"packets\", starting with the or , then the packet number, then the complement of the packet number, in the same fashion as the original XMODEM packet header.\nThe window size was normally set to six packets.\nSEAlink was not expected to operate over X.25 or similar links, and thus did not perform escaping.\nThis was also needed so the zero packet would work properly, as this standard used the character that WXmodem had re-purposed.\nOn top of these changes, it added an \"Overdrive\" mode for half duplex links.\nThis suppressed ACKs for packets that were successfully transferred, in effect making the window of infinite size.\nThis mode was indicated by a flag in the zero block.\nSEAlink later added a number of other improvements and was a useful general-purpose protocol.\nHowever, it remained rare outside the FidoNet world, and was rarely seen in user-facing software.\n\n## XMODEM-1K\nAnother way to solve the throughput problem is to increase the packet size.\nAlthough the fundamental problem of latency remains, the speed at which it becomes a problem is higher.\nXMODEM-1K with 1024-byte packets was the most popular such solution.\nIn this case, the throughput at 9600 bit/s is 81%, given the same assumptions as above.\nXMODEM-1K was an expanded version of XMODEM-CRC, which indicated the longer block size in the sender by starting a packet with the character instead of .\nLike other backward-compatible XMODEM extensions, it was intended that a -1K transfer could be started with any implementation of XMODEM on the other end, backing off features as required.\nXMODEM-1K was originally one of the many improvements to XMODEM introduced by [Chuck Forsberg](https://bliptext.com/articles/chuck-forsberg) in his [YMODEM](https://bliptext.com/articles/ymodem) protocol.\nForsberg suggested that the various improvements were optional, expecting software authors to implement as many of them as possible.\nInstead, 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.\nThus XMODEM-1K actually post-dates YMODEM, but remained fairly common anyway.\n\n## NMODEM\nNMODEM is a [file transfer](https://bliptext.com/articles/file-transfer) protocol developed by L. B. Neal, who released it in 1990.\nNMODEM is essentially a version of XMODEM-CRC using larger 2048 byte blocks, as opposed to XMODEM's 128 byte blocks.\nNMODEM was implemented as a separate program, written in Turbo Pascal 5.0 for the [IBM PC compatible](https://bliptext.com/articles/ibm-pc-compatible) family of computers.\nThe block size was chosen to match the common cluster size of the [MS-DOS](https://bliptext.com/articles/ms-dos) [FAT](https://bliptext.com/articles/file-allocation-table) file system on contemporary [hard drives](https://bliptext.com/articles/hard-drive), making buffering data for writing simpler.\n\n## Protocol spoofing\nOver reliable (error-free) connections, it is possible to eliminate latency by \"pre-acknowledging\" the packets, a technique known more generally as \"[protocol spoofing](https://bliptext.com/articles/protocol-spoofing)\".\nThis is normally accomplished in the link hardware, notably Telebit modems.\nThe modems, when the option was turned on, would notice the XMODEM header and immediately sent an.\nThis would cause the sending XMODEM program to immediately send the next packet, making the transfer continuous, like an infinite-sized window.\nThe modems also suppress the being sent by the XMODEM software at the far end, thereby freeing up the low-speed return channel.\nThe system can also be implemented in the protocol itself, and variations of XMODEM offered this feature.\nIn these cases, the receiver would send the as soon as the packet started, in the same fashion as the Telebit modems.\nSince this feature is only an alteration of the receiver-side behavior, it does not require any changes in the protocol on the sender's side.\n[YMODEM](https://bliptext.com/articles/ymodem) formalized this system.\nThis concept should be contrasted with the one used in SEAlink, which changes the behavior on both sides of the link.\nIn SEAlink, the receiver stops sending the entirely, and the sender changes its behavior to not expect them.\n\n# Citations","current_revision":null,"created_by":"kACnuQmH5k9Nr5VNVEpVeg7XpvUmMctD","created_at":"2025-01-25T21:13:04.036Z","updated_at":"2025-01-25T21:13:04.036Z","search_vector":"'xmodem':1","search_content":" \n**Title:** XMODEM \n**Purpose:** file transfer protocol \n**Developer:** [Ward Christensen](https://bliptext.com/articles/ward-christensen) \n**Date:** 1977 \n**Influenced:** [YMODEM](https://bliptext.com/articles/ymodem), many others \n**Hardware:** [modems](https://bliptext.com/articles/modem) \n \n\n# \n**XMODEM** is a simple [file transfer](https://bliptext.com/articles/file-transfer) protocol developed as a quick [hack](https://bliptext.com/articles/hacker-hobbyist) by [Ward Christensen](https://bliptext.com/articles/ward-christensen) for use in his 1977 **MODEM.ASM** [terminal program](https://bliptext.com/articles/terminal-program).\nIt allowed users to transmit files between their computers when both sides used MODEM.\nKeith Petersen made a minor update to always turn on \"quiet mode\", and called the result XMODEM.\nXMODEM, like most file transfer protocols, breaks up the original data into a series of \"[packets](https://bliptext.com/articles/packet-information-technology)\" that are sent to the receiver, along with additional information allowing the receiver to determine whether that packet was correctly received.\nIf an error is detected, the receiver requests that the packet be re-sent.\nA string of bad packets causes the transfer to abort.\nXMODEM became extremely popular in the early [bulletin board system](https://bliptext.com/articles/bulletin-board-system) (BBS) market, largely because it was simple to implement.\nIt 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.\nChristensen believed his original XMODEM to be \"the single most modified program in computing history\".\n[Chuck Forsberg](https://bliptext.com/articles/chuck-forsberg) collected a number of common modifications into his [YMODEM](https://bliptext.com/articles/ymodem) protocol, but poor implementation led to a further fracturing before they were re-unified by his later [ZMODEM](https://bliptext.com/articles/zmodem) protocol.\nZMODEM became very popular, but never completely replaced XMODEM in the BBS market.\n\n# Packet structure\nThe original XMODEM used a 128-byte data packet, the basic block size used on [CP/M](https://bliptext.com/articles/cp-m) [floppy disks](https://bliptext.com/articles/floppy-disk).\nThe packet was prefixed by a simple 3-byte header containing a character, a \"block number\" from 1-255, and the \"inverse\" block number—255 minus the block number.\nBlock numbering starts with 1 for the first block sent, not 0.\nThe header was followed by the 128 bytes of data, and then a single-byte [checksum](https://bliptext.com/articles/checksum).\nThe checksum was the sum of all 128 data bytes in the packet [modulo](https://bliptext.com/articles/modulo-operation) 256.\nThe complete packet was thus 132 bytes long, containing 128 bytes of [payload data](https://bliptext.com/articles/payload-computing), for a total [channel efficiency](https://bliptext.com/articles/channel-efficiency) of about 97%.\nThe file was marked \"complete\" with a character sent after the last block.\nThis character was not in a packet, but sent alone as a single byte.\nSince the file length was not sent as part of the protocol, the last packet was padded out with a \"known character\" that could be dropped.\nIn the original specification, this defaulted to or 26 decimal, which CP/M used as the end-of-file marker inside its own disk format.\nThe standard suggested any character could be used for padding, but there was no way for it to be changed within the protocol itself – if an implementation changed the padding character, only clients using the same implementation would correctly interpret the new padding character.\n\n# Transfer details\nFiles were transferred one packet at a time.\nWhen 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.\nIf the two matched, the receiver sent an message back to the sender, which then sent the next packet in sequence.\nIf there was a problem with the checksum, the receiver instead sent a .\nIf a was received, the sender would re-send the packet, and continued to try several times, normally ten, before aborting the transfer.\nA 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 character.\nA seven-second timeout was also used within a packet, guarding against dropped connections in mid-packet.\nThe block numbers were also examined in a simple way to check for errors.\nAfter receiving a packet successfully, the next packet should have a one-higher number.\nIf it instead received the same block number this was not considered serious, it was implied that the had not been received by the sender, which had then re-sent the packet.\nAny other packet number signalled that packets had been lost.\nTransfers were receiver-driven; the transmitter would not send any data until an initial was sent by the receiver.\nThis was a logical outcome of the way the user interacted with the sending machine, which would be remotely located.\nThe user would navigate to the requested file on the sending machine, and then ask that machine to transfer it.\nOnce this command was issued, the user would then execute a command in their local software to start receiving.\nSince the delay between asking the remote system for the file and issuing a local command to receive was unknown, XMODEM allowed up to 90 seconds for the receiver to begin issuing requests for data packets.\n\n# Problems\nAlthough XMODEM was robust enough for a journalist in 1982 to transmit stories from Pakistan to the United States with an [Osborne 1](https://bliptext.com/articles/osborne-1) and [acoustic coupler](https://bliptext.com/articles/acoustic-coupler) over poor-quality telephone lines, the protocol had several flaws.\n\n## Minor problems\nXMODEM was written for [CP/M](https://bliptext.com/articles/cp-m) machines, and bears several marks of that [operating system](https://bliptext.com/articles/operating-system).\nNotably, files on CP/M were always multiples of 128 bytes, and their end was marked within a block with the character.\nThese characteristics were transplanted directly into XMODEM.\nHowever, other operating systems did not feature either of these peculiarities, and the widespread introduction of [MS-DOS](https://bliptext.com/articles/ms-dos) in the early 1980s led to XMODEM having to be updated to notice either a or as the end-of-file marker.\nFor some time it was suggested that sending a character instead of an or should be supported in order to easily abort the transfer from the receiving end.\nLikewise, a received in place of the indicated the sender wished to cancel the transfer.\nHowever, this character could be easily \"created\" via simple noise-related errors of what was meant to be an or .\nA double- was proposed to avoid this problem, but it is not clear if this was widely implemented.\n\n## Major problems\nXMODEM was designed for simplicity, without much knowledge of other file transfer protocols – which were fairly rare anyway.\nDue 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.\nMost 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.\nAdditionally, similar damage to the header or checksum could lead to a failed transfer in cases where the data itself was undamaged.\nMany authors introduced extensions to XMODEM to address these and other problems.\nMany asked for these extensions to be included as part of a new XMODEM standard.\nHowever, 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.\nAs he explained:\n\n# Batch transfers\nAnother problem with XMODEM was that it required the transfer to be user-driven rather than automated.\nTypically this meant the user would navigate on the sender's system to select the file they wanted, and then use a command to put that system into the \"ready to send\" mode.\nThey would then trigger the transfer from their end using a command in their terminal emulator.\nIf the user wanted to transfer another file, they would have to repeat this process again.\nFor automated transfers between two sites, a number of add-ons to the XMODEM protocol were implemented over time.\nThese generally assumed the sender would continue sending file after file, with the receiver attempting to trigger the next file by sending a as normal at the start of a transfer.\nWhen the s timed out, it could be assumed that either there were no more files, or the link was broken anyway.\n\n## MODEM7\n**MODEM7**, also known as **MODEM7** batch or **Batch XMODEM**, was the first known extension of the XMODEM protocol.\nA normal XMODEM file transfer starts with the receiver sending a single character to the sender, which then starts sending a single to indicate the start of the data, and then packets of data.\nMODEM7 changed this behavior only slightly, by sending the filename, in [8.3 filename](https://bliptext.com/articles/8-3-filename) format, before the .\nEach character was sent individually and had to be echoed by the receiver as a form of error correction.\nFor a non-aware XMODEM implementation, this data would simply be ignored while it waited for the to arrive, so the characters would not be echoed and the implementation could fall back to conventional XMODEM.\nWith \"aware\" software, the file name could be used to save the file locally.\nTransfers could continue with another, each file is saved under the name being sent to the receiver.\n[Jerry Pournelle](https://bliptext.com/articles/jerry-pournelle) in 1983 described MODEM7 as \"probably the most popular microcomputer communications program in existence\".\n\n## TeLink\nMODEM7 sent the filename as normal text, which meant it could be corrupted by the same problems that XMODEM was attempting to avoid.\nThis led to the introduction of **TeLink** by [Tom Jennings](https://bliptext.com/articles/tom-jennings), author of the original [FidoNet](https://bliptext.com/articles/fidonet) mailers.\nTeLink avoided MODEM7's problems by standardizing a new \"zero packet\" containing information about the original file.\nThis included the file's name, size, and [timestamp](https://bliptext.com/articles/timestamp), which were placed in a regular 128 byte XMODEM block.\nWhereas a normal XMODEM transfer would start with the sender sending \"block 1\" with a header, the TeLink header packet was labeled \"block 0\" and began with a.\nThe packet contained the file creation date and time, filename up to 16 characters, the file size as a 4-byte value, and the name of the program sending the file.\nA normal XMODEM implementation would simply discard the packet, the assumption being that the packet number had been corrupted.\nBut this led to a potential time delay if the packet were discarded, as the sender could not tell whether the receiver had responded with a because it did not understand the zero packet or because there was a transmission error.\nAs TeLink was normally used only by [FidoNet](https://bliptext.com/articles/fidonet) software, which demanded it as part of the [FidoNet](https://bliptext.com/articles/fidonet) standards, this did not present a real-world problem as both ends would always support this standard.\nThe basic \"block 0\" system became a standard in the FidoNet community, and was re-used by a number of future protocols like [SEAlink](https://bliptext.com/articles/sealink) and [YMODEM](https://bliptext.com/articles/ymodem).\n\n# XMODEM-CRC\nThe checksum used in the original protocol was extremely simple, and errors within the packet could go unnoticed.\nThis led to the introduction of **XMODEM-[CRC](https://bliptext.com/articles/cyclic-redundancy-check)** by John Byrns, which used a 16-bit [CRC](https://bliptext.com/articles/cyclic-redundancy-check) in place of the 8-bit checksum.\nCRCs 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.\nStatistically, this made the chance of detecting an error less than 16 bits long 99.9969%, and even higher for longer error bit strings.\nXMODEM-CRC was designed to be backwardly compatible with XMODEM.\nTo do this, the receiver sent a C (capital C) character instead of a to start the transfer.\nIf 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 to start a \"traditional\" XMODEM transfer.\nUnfortunately, this attempt at backward compatibility had a downside.\nSince 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.\nThe receiver thus tried to start the transfer three times with C, waiting three seconds between each attempt.\nThis 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.\nTo 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.\nTo the average user, XMODEM-CRC was essentially a \"second protocol\", and treated as such.\nThis was not true of FidoNet mailers, however, where CRC was defined as the standard for all TeLink transfers.\n\n# Higher throughput\nSince the XMODEM protocol required the sender to stop and wait for an or message from the receiver, it tended to be quite slow.\nIn the era of 300 bit/s modems, the entire 132-byte packet required 4.4 seconds to send (132 bytes * (8 bits per byte + 1 start bit + 1 stop bit) / 300 bits per second).\nAssuming it takes 0.2 seconds for the receiver's 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 4.6 seconds, just over 92% channel efficiency.\nThe time for the / process was a fixed function of the underlying communications network, not of the performance of the modems.\nAs modem speeds increased, the fixed delay grew in proportion to time needed to send the packet.\nFor instance, at 2400 bit/s the packets took only 0.55 seconds to send, so if the / still took 0.2 seconds to make it back to the user's machine, the efficiency has fallen to 71%.\nAt 9600 bit/s it is just under 40% – more time is spent waiting for the reply than is needed to send the packet.\nA number of new versions of XMODEM were introduced in order to address these problems.\nLike earlier extensions, these versions tended to be backward-compatible with the original XMODEM, and like those extensions, this led to further fracturing of the XMODEM landscape in the user's terminal emulator.\nIn the end, dozens of versions of XMODEM emerged.\n\n## WXModem\n**WXmodem**, short for \"Windowed Xmodem\", is a variant of XMODEM developed by Peter Boswell in 1986 for use on high-latency lines, specifically public [X.25](https://bliptext.com/articles/x-25) systems and [PC Pursuit](https://bliptext.com/articles/pc-pursuit).\nThese have latencies that are far higher than the [plain-old telephone service](https://bliptext.com/articles/plain-old-telephone-service), which leads to very poor efficiency in XMODEM.\nAdditionally, these networks often use [control characters](https://bliptext.com/articles/control-character) for [flow control](https://bliptext.com/articles/flow-control-data) and other tasks, notably [XON/XOFF](https://bliptext.com/articles/xon-xoff) will stop the data flow.\nFinally, in the case of an error that required a resend, it was sometimes difficult to know whether a was a packet indicator or more noise.\nWXmodem adapted XMODEM-CRC to address these problems.\nOne change was to escape a small set of control characters:, , and.\nThese were escaped by inserting a in front of them, and then modifying the character by XORing it with 64.\nIn theory, this meant the packet might be as long as 264 bytes if it originally consisted entirely of characters that required escaping.\nThese inserted and modified characters are not part of the CRC calculation, they are removed and converted at the receiving end before calculating the CRC.\nAdditionally, all packets were prefixed with a character, which meant the packet lead-in was , reducing the chance that a stray would be confused for a packet header in various error cases.\nAn unescaped found in the body of a packet was an error.\nThe major change in WXMODEM is the use of a [sliding window](https://bliptext.com/articles/sliding-window) to improve throughput on high-latency links.\nTo do so, the messages were followed by the packet number they were ing or ing.\nThe receiver does not have to every packet; it is allowed to any number between one and four packets.\nAn with the fourth packet sequence number is assumed to all four packets.\nAn error causes a to be sent immediately, with all packets from that number and after being re-sent.\nRequiring an every four packets makes the system work like it has a packet size of 512 bytes, but in the case of an error, typically only requires 128 bytes to be re-sent.\nMoreover, it reduces the amount of data flowing in the reverse direction by four times.\nThis is of little interest in the typical modem's [full duplex](https://bliptext.com/articles/full-duplex) operation, but is important in [half duplex](https://bliptext.com/articles/half-duplex) systems like [Telebit](https://bliptext.com/articles/telebit) models which have 19 kB speed in one direction and 75 bits/s in the return channel.\n\n## SEAlink\nOne of the first third-party mailers for the [FidoNet](https://bliptext.com/articles/fidonet) system was **SEAdog**, written by the same author as the then-popular [.arc](https://bliptext.com/articles/arc) [data compression](https://bliptext.com/articles/data-compression) format.\nSEAdog included a wide variety of improvements, including [SEAlink](https://bliptext.com/articles/sealink), an improved transfer protocol based on the same sliding window concept as WXmodem.\nIt differed from WXmodem mostly in details.\nOne difference is that SEAlink supported the \"zero packet\" introduced by TeLink, which is needed in order to operate as a drop-in replacement for TeLink in FidoNet systems where the header was expected.\ns and s were extended to three-byte \"packets\", starting with the or , then the packet number, then the complement of the packet number, in the same fashion as the original XMODEM packet header.\nThe window size was normally set to six packets.\nSEAlink was not expected to operate over X.25 or similar links, and thus did not perform escaping.\nThis was also needed so the zero packet would work properly, as this standard used the character that WXmodem had re-purposed.\nOn top of these changes, it added an \"Overdrive\" mode for half duplex links.\nThis suppressed ACKs for packets that were successfully transferred, in effect making the window of infinite size.\nThis mode was indicated by a flag in the zero block.\nSEAlink later added a number of other improvements and was a useful general-purpose protocol.\nHowever, it remained rare outside the FidoNet world, and was rarely seen in user-facing software.\n\n## XMODEM-1K\nAnother way to solve the throughput problem is to increase the packet size.\nAlthough the fundamental problem of latency remains, the speed at which it becomes a problem is higher.\nXMODEM-1K with 1024-byte packets was the most popular such solution.\nIn this case, the throughput at 9600 bit/s is 81%, given the same assumptions as above.\nXMODEM-1K was an expanded version of XMODEM-CRC, which indicated the longer block size in the sender by starting a packet with the character instead of .\nLike other backward-compatible XMODEM extensions, it was intended that a -1K transfer could be started with any implementation of XMODEM on the other end, backing off features as required.\nXMODEM-1K was originally one of the many improvements to XMODEM introduced by [Chuck Forsberg](https://bliptext.com/articles/chuck-forsberg) in his [YMODEM](https://bliptext.com/articles/ymodem) protocol.\nForsberg suggested that the various improvements were optional, expecting software authors to implement as many of them as possible.\nInstead, 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.\nThus XMODEM-1K actually post-dates YMODEM, but remained fairly common anyway.\n\n## NMODEM\nNMODEM is a [file transfer](https://bliptext.com/articles/file-transfer) protocol developed by L. B. Neal, who released it in 1990.\nNMODEM is essentially a version of XMODEM-CRC using larger 2048 byte blocks, as opposed to XMODEM's 128 byte blocks.\nNMODEM was implemented as a separate program, written in Turbo Pascal 5.0 for the [IBM PC compatible](https://bliptext.com/articles/ibm-pc-compatible) family of computers.\nThe block size was chosen to match the common cluster size of the [MS-DOS](https://bliptext.com/articles/ms-dos) [FAT](https://bliptext.com/articles/file-allocation-table) file system on contemporary [hard drives](https://bliptext.com/articles/hard-drive), making buffering data for writing simpler.\n\n## Protocol spoofing\nOver reliable (error-free) connections, it is possible to eliminate latency by \"pre-acknowledging\" the packets, a technique known more generally as \"[protocol spoofing](https://bliptext.com/articles/protocol-spoofing)\".\nThis is normally accomplished in the link hardware, notably Telebit modems.\nThe modems, when the option was turned on, would notice the XMODEM header and immediately sent an.\nThis would cause the sending XMODEM program to immediately send the next packet, making the transfer continuous, like an infinite-sized window.\nThe modems also suppress the being sent by the XMODEM software at the far end, thereby freeing up the low-speed return channel.\nThe system can also be implemented in the protocol itself, and variations of XMODEM offered this feature.\nIn these cases, the receiver would send the as soon as the packet started, in the same fashion as the Telebit modems.\nSince this feature is only an alteration of the receiver-side behavior, it does not require any changes in the protocol on the sender's side.\n[YMODEM](https://bliptext.com/articles/ymodem) formalized this system.\nThis concept should be contrasted with the one used in SEAlink, which changes the behavior on both sides of the link.\nIn SEAlink, the receiver stops sending the entirely, and the sender changes its behavior to not expect them.\n\n# Citations","revisionCount":0},"hasMore":false,"nextCursor":null}}

History