Editing XMODEM (section)

==Higher throughput==
Since the XMODEM protocol required the sender to stop and wait for an <kbd><ACK></kbd> or <kbd><NAK></kbd> message from the receiver, it tended to be quite slow. In the era of 300&nbsp;bit/s modems, the entire 132-byte packet required 4.4&nbsp;seconds to send (132 bytes * (8 bits per byte + 1 start bit + 1 stop bit) / 300 bits per second). Assuming it takes 0.2&nbsp;seconds for the receiver's <kbd><ACK></kbd> to make it back to the sender and the next packet to start hitting the receiver (0.1&nbsp;seconds in both directions), the overall time for one packet would be 4.6&nbsp;seconds, just over 92% channel efficiency.

The time for the <kbd><ACK></kbd>/<kbd><NAK></kbd> process was a fixed function of the underlying communications network, not of the performance of the modems. As modem speeds increased, the fixed delay grew in proportion to time needed to send the packet. For instance, at 2400&nbsp;bit/s the packets took only 0.55&nbsp;seconds to send, so if the <kbd><ACK></kbd>/<kbd><NAK></kbd> still took 0.2&nbsp;seconds to make it back to the user's machine, the efficiency has fallen to 71%. At 9600&nbsp;bit/s it is just under 40% – 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 further fracturing of the XMODEM landscape in the user's terminal emulator. In the end, dozens of versions of XMODEM emerged.

===WXModem===
'''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]] systems and [[PC Pursuit]]. These have latencies that are far higher than the [[plain-old telephone service]], which leads to very poor efficiency in XMODEM. Additionally, these networks often use [[control character]]s for [[Flow control (data)|flow control]] and other tasks, notably [[XON/XOFF]] will stop the data flow. Finally, in the case of an error that required a resend, it was sometimes difficult to know whether a <code>SOH</code> was a packet indicator or more noise. WXmodem adapted XMODEM-CRC to address these problems.{{sfn|Boswell|1986}}

One change was to escape a small set of control characters: <code>DLE</code>, <code>XON</code>, <code>XOFF</code> and <code>SYN</code>. These were escaped by inserting a <code>DLE</code> in front of them, and then modifying the character by XORing it with 64. In theory, this meant the packet might be as long as 264 bytes if it originally consisted entirely of characters that required escaping. These inserted and modified characters are not part of the CRC calculation, they are removed and converted at the receiving end before calculating the CRC.{{sfn|Boswell|1986}}

Additionally, all packets were prefixed with a <code>SYN</code> character, which meant the packet lead-in was <code>SYN</code><code>SOH</code>, reducing the chance that a stray <code>SOH</code> would be confused for a packet header in various error cases. An unescaped <code>SYN</code> found in the body of a packet was an error.{{sfn|Boswell|1986}}

The major change in WXMODEM is the use of a [[sliding window]] to improve throughput on high-latency links. To do so, the <code>ACK</code> messages were followed by the packet number they were <code>ACK</code>ing or <code>NAK</code>ing. The receiver does not have to <code>ACK</code> every packet; it is allowed to <code>ACK</code> any number between one and four packets. An <code>ACK</code> with the fourth packet sequence number is assumed to <code>ACK</code> all four packets. An error causes a <code>NAK</code> to be sent immediately, with all packets from that number and after being re-sent.{{sfn|Boswell|1986}}

Requiring an <code>ACK</code> every four packets makes the system work like it has a packet size of 512&nbsp;bytes, but in the case of an error, typically only requires 128&nbsp;bytes to be re-sent. Moreover, it reduces the amount of data flowing in the reverse direction by four times. This is of little interest in the typical modem's [[full duplex]] operation, but is important in [[half duplex]] systems like [[Telebit]] models which have 19&nbsp;kB speed in one direction and 75&nbsp;bits/s in the return channel.

===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 based on the same sliding window concept as WXmodem.{{sfn|SEAlink|1987}} It differed from WXmodem mostly in details.

One 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. <code>ACK</code>s and <code>NAK</code>s were extended to three-byte "packets", starting with the <code>ACK</code> or <code>NAK</code>, then the packet number, then the complement of the packet number, in the same fashion as the original XMODEM packet header. The window size was normally set to six packets.{{sfn|SEAlink|1987}}

SEAlink was not expected to operate over X.25 or similar links, and thus did not perform escaping. This was also needed so the zero packet would work properly, as this standard used the <code>SYN</code> character that WXmodem had re-purposed.{{sfn|SEAlink|1987}} On top of these changes, it added an "Overdrive" mode for half duplex links. This suppressed ACKs for packets that were successfully transferred, in effect making the window of infinite size. This mode was indicated by a flag in the zero block.{{sfn|SEAlink|1987}}

SEAlink later added a number of other improvements and was a useful general-purpose protocol. However, it remained rare outside the FidoNet world, and was rarely seen in user-facing software.

===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{{r|meeks198902}} was the most popular such solution. In this case, the throughput at 9600&nbsp;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 <kbd><STX></kbd> character instead of <kbd><SOH></kbd>. Like 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.

XMODEM-1K was originally one of the many improvements to XMODEM introduced by [[Chuck Forsberg]] in his [[YMODEM]] protocol. 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. Thus XMODEM-1K actually post-dates YMODEM, but remained fairly common anyway.

===NMODEM===
NMODEM is a [[file transfer]] protocol developed by L. B. Neal, who released it in 1990. NMODEM is essentially a version of XMODEM-CRC using larger 2048 byte blocks, as opposed to XMODEM's 128 byte blocks.
NMODEM was implemented as a separate program, written in Turbo Pascal 5.0 for the [[IBM PC compatible]] family of computers. The block size was chosen to match the common cluster size of the [[MS-DOS]] [[File Allocation Table|FAT]] file system on contemporary [[hard drive]]s, making buffering data for writing simpler.<ref>{{cite web |url=http://www.cpeterso.com/protocols/NMODM112.ARJ |title=NMODEM 1.12 program and source code |archive-url=https://web.archive.org/web/20110807213052/http://www.cpeterso.com/code/protocols/NMODM112.ARJ |archive-date=2011-08-07 |url-status=dead |access-date=2020-02-13 }}</ref><ref>{{cite web |url=http://www.cpeterso.com/protocols/NMODEM.TXT |title=NMODEM documentation |archive-url=https://web.archive.org/web/20160409012002/https://www.cpeterso.com/code/protocols/NMODEM.TXT |archive-date=2016-04-09 |url-status=dead |access-date=2020-02-13 }}</ref>

===Protocol spoofing===
Over reliable (error-free) connections, it is possible to eliminate latency by "pre-acknowledging" the packets, a technique known more generally as "[[protocol spoofing]]". This is normally accomplished in the link hardware, notably Telebit modems. The modems, when the option was turned on, would notice the XMODEM header and immediately sent an <code>ACK</code>. This would cause the sending XMODEM program to immediately send the next packet, making the transfer continuous, like an infinite-sized window. The modems also suppress the <code>ACK</code> being sent by the XMODEM software at the far end, thereby freeing up the low-speed return channel.

The system can also be implemented in the protocol itself, and variations of XMODEM offered this feature. In these cases, the receiver would send the <code>ACK</code> as soon as the packet started, in the same fashion as the Telebit modems. Since 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. [[YMODEM]] formalized this system.

This concept should be contrasted with the one used in SEAlink, which changes the behavior on both sides of the link. In SEAlink, the receiver stops sending the <code>ACK</code> entirely, and the sender changes its behavior to not expect them.