- 1 - XMODEM/YMODEM PROTOCOL REFERENCE A compendium of documents describing the XMODEM and YMODEM File Transfer Protocols This document was formatted 10-27-87. Edited by Chuck Forsberg Please distribute as widely as possible. Questions to Chuck Forsberg Omen Technology Inc The High Reliability Software 17505-V Sauvie Island Road Portland Oregon 97231 VOICE: 503-621-3406 :VOICE Modem (TeleGodzilla): 503-621-3746 Speed 19200(Telebit PEP),2400,1200,300 CompuServe: 70007,2304 GEnie: CAF UUCP: ...!tektronix!reed!omen!caf - 2 - 1. TOWER OF BABEL A "YMODEM Tower of Babel" has descended on the microcomputing community bringing with it confusion, frustration, bloated phone bills, and wasted man hours. Sadly, I (Chuck Forsberg) am partly to blame for this mess. As author of the early 1980s batch and 1k XMODEM extensions, I assumed readers of earlier versions of this document would implement as much of the YMODEM protocol as their programming skills and computing environments would permit. This proved a rather naive assumption as programmers motivated by competitive pressure implemented as little of YMODEM as possible. Some have taken whatever parts of YMODEM that appealed to them, applied them to MODEM7 Batch, Telink, XMODEM or whatever, and called the result YMODEM. Jeff Garbers (Crosstalk package development director) said it all: "With protocols in the public domain, anyone who wants to dink around with them can go ahead." [1] Documents containing altered examples derived from YMODEM.DOC have added to the confusion. In one instance, the heading in YMODEM.DOC's Figure 1 has mutated from "1024 byte Packets" to "YMODEM/CRC File Transfer Protocol". None of the XMODEM and YMODEM examples shown in that document were correct. To put an end to this confusion, we must make "perfectly clear" what YMODEM stands for, as Ward Christensen defined it in his 1985 coining of the term. To the majority of you who read, understood, and respected Ward's definition of YMODEM, I apologize for the inconvenience. 1.1 Definitions ARC ARC is a program that compresses one or more files into an archive and extracts files from such archives. XMODEM refers to the file transfer etiquette introduced by Ward Christensen's 1977 MODEM.ASM program. The name XMODEM comes from Keith Petersen's XMODEM.ASM program, an adaptation of MODEM.ASM for Remote CP/M (RCPM) systems. It's also called the MODEM or MODEM2 protocol. Some who are unaware of MODEM7's unusual batch file mode call it MODEM7. Other aliases include "CP/M Users' Group" and "TERM II FTP 3". The name XMODEM caught on partly because it is distinctive and partly because of media interest in __________ 1. Page C/12, PC-WEEK July 12, 1987 Chapter 1 X/YMODEM Protocol Reference 10-27-87 3 bulletin board and RCPM systems where it was accessed with an "XMODEM" command. This protocol is supported by every serious communications program because of its universality, simplicity, and reasonable performance. XMODEM/CRC replaces XMODEM's 1 byte checksum with a two byte Cyclical Redundancy Check (CRC-16), giving modern error detection protection. XMODEM-1k Refers to the XMODEM/CRC protocol with 1024 byte data blocks. YMODEM Refers to the XMODEM/CRC (optional 1k blocks) protocol with batch transmission as described below. In a nutshell, YMODEM means BATCH. YMODEM-g Refers to the streaming YMODEM variation described below. True YMODEM(TM) In an attempt to sort out the YMODEM Tower of Babel, Omen Technology has trademarked the term True YMODEM(TM) to represent the complete YMODEM protocol described in this document, including pathname, length, and modification date transmitted in block 0. Please contact Omen Technology about certifying programs for True YMODEM(TM) compliance. ZMODEM uses familiar XMODEM/CRC and YMODEM technology in a new protocol that provides reliability, throughput, file management, and user amenities appropriate to contemporary data communications. ZOO Like ARC, ZOO is a program that compresses one or more files into a "zoo archive". ZOO supports many different operating systems including Unix and VMS. Chapter 1 X/YMODEM Protocol Reference 10-27-87 4 2. YMODEM MINIMUM REQUIREMENTS All programs claiming to support YMODEM must meet the following minimum requirements: + The sending program shall send the pathname (file name) in block 0. + The pathname shall be a null terminated ASCII string as described below. + The receiving program shall use this pathname for the received file name, unless explicitly overridden. + The sending program shall use CRC-16 in response to a "C" pathname nak, otherwise use 8 bit checksum. + The receiving program must accept any mixture of 128 and 1024 byte blocks within each file it receives. Sending programs may switch between 1024 and 128 byte blocks at the end of file(s), and when the frequency of retransmissions so suggests. + The sending program must not change the length of an unacknowledged block. + At the end of each file, the sending program shall send EOT up to ten times until it receives an ACK character. (This is part of the XMODEM spec.) + The end of a transfer session shall be signified by a null (empty) pathname. Programs not meeting all of these requirements are not YMODEM compatible, and shall not be described as supporting YMODEM. Meeting these MINIMUM requirements does not guarantee reliable file transfers under stress. Particular attention is called to XMODEM's single character supervisory messages that are easily corrupted by transmission errors. Chapter 2 X/YMODEM Protocol Reference 10-27-87 5 3. WHY YMODEM? Since its development half a decade ago, the Ward Christensen modem protocol has enabled a wide variety of computer systems to interchange data. There is hardly a communications program that doesn't at least claim to support this protocol. Advances in computing, modems and networking have revealed a number of weaknesses in the original protocol: + The short block length caused throughput to suffer when used with timesharing systems, packet switched networks, satellite circuits, and buffered (error correcting) modems. + The 8 bit arithmetic checksum and other aspects allowed line impairments to interfere with dependable, accurate transfers. + Only one file could be sent per command. The file name had to be given twice, first to the sending program and then again to the receiving program. + The transmitted file could accumulate as many as 127 extraneous bytes. + The modification date of the file was lost. A number of other protocols have been developed over the years, but none have displaced XMODEM to date: + Lack of public domain documentation and example programs have kept proprietary protocols such as Blast, Relay, and others tightly bound to the fortunes of their suppliers. + Complexity discourages the widespread application of BISYNC, SDLC, HDLC, X.25, and X.PC protocols. + Performance compromises and complexity have limited the popularity of the Kermit protocol, which was developed to allow file transfers in environments hostile to XMODEM. The XMODEM protocol extensions and YMODEM Batch address some of these weaknesses while maintaining most of XMODEM's simplicity. YMODEM is supported by the public domain programs YAM (CP/M), YAM(CP/M-86), YAM(CCPM-86), IMP (CP/M), KMD (CP/M), rz/sz (Unix, Xenix, VMS, Berkeley Unix, Venix, Xenix, Coherent, IDRIS, Regulus). Commercial implementations include MIRROR, and Professional-YAM.[1] Communications Chapter 3 X/YMODEM Protocol Reference 10-27-87 6 programs supporting these extensions have been in use since 1981. The 1k block length (XMODEM-1k) described below may be used in conjunction with YMODEM Batch Protocol, or with single file transfers identical to the XMODEM/CRC protocol except for minimal changes to support 1k blocks. Another extension is the YMODEM-g protocol. YMODEM-g provides batch transfers with maximum throughput when used with end to end error correcting media, such as X.PC and error correcting modems, including 9600 bps units by TeleBit, U.S.Robotics, Hayes, Electronic Vaul...
Amiga7878