Editing XMODEM (section)

==Batch transfers==
Another problem with XMODEM was that it required the transfer to be user-driven rather than automated.{{r|meeks198902}} Typically 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. They would then trigger the transfer from their end using a command in their terminal emulator. If the user wanted to transfer another file, they would have to repeat this process again.

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 <code>NAK</code> as normal at the start of a transfer. When the <code>NAK</code>s timed out, it could be assumed that either there were no more files, or the link was broken anyway.

===MODEM7===
'''MODEM7''', also known as '''MODEM7 batch''' or '''Batch XMODEM''', was the first known extension of the XMODEM protocol. A normal XMODEM file transfer starts with the receiver sending a single <code>NAK</code> character to the sender, which then starts sending a single <code>SOH</code> to indicate the start of the data, and then packets of data.

MODEM7 changed this behavior only slightly, by sending the filename, in [[8.3 filename]] format, before the <kbd><SOH></kbd>. Each character was sent individually and had to be echoed by the receiver as a form of error correction. For a non-aware XMODEM implementation, this data would simply be ignored while it waited for the <code>SOH</code> to arrive, so the characters would not be echoed and the implementation could fall back to conventional XMODEM. With "aware" software, the file name could be used to save the file locally. Transfers could continue with another <code><NAK></code>, each file is saved under the name being sent to the receiver.

[[Jerry Pournelle]] in 1983 described MODEM7 as "probably the most popular microcomputer communications program in existence".<ref name="pournelle198307">{{cite news | url=https://archive.org/stream/byte-magazine-1983-07-rescan/1983_07_BYTE_08-07_Videotex#page/n334/mode/2up | title=Interstellar Drives, Osborne Accessories, DEDICATE/32, and Death Valley | work=BYTE | date=July 1983 | access-date=28 August 2016 | author=Pournelle, Jerry | page=334}}</ref>

===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" with a <code><SOH></code> header, the TeLink header packet was labeled "block 0" and began with a <code><SYN></code>. The 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.{{sfn|Bush|1995|p=G.1}}

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 tell whether the receiver had responded with a <code><NAK></code> because it did not understand the zero packet or because there was a transmission error. As TeLink was normally used only by [[FidoNet]] software, which demanded it as part of the FidoNet standards, this did not present a real-world problem as both ends would always support this standard.{{sfn|Bush|1995|p=G.1}}

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]].