jjung@sal52.usc.edu (John Jung) (10/13/88)
I don't know if any of you have read a similar request on alt.bbs, but I have a question : Can some one send me a simple, easy to understand, and non-machine specific (read : like the article about X/YModem which was very easy to understand) on the following protocols : * Zmodem * Fmodem * YModem-g * CompuServe B If you have a text file with information on how these protocls are structured, and not listings of how to implement them on Un*x, please post, or E-mail them to me. Many thanks. John
caf@omen.UUCP (Chuck Forsberg WA7KGX) (10/15/88)
In article <1619@nunki.usc.edu> jjung@sal52.usc.edu (John Jung) writes: : : I don't know if any of you have read a similar request on alt.bbs, but I have :a question : : : Can some one send me a simple, easy to understand, and non-machine specific :(read : like the article about X/YModem which was very easy to understand) on the :following protocols : : : * Zmodem : * Fmodem : * YModem-g : * CompuServe B YMODEM-g is merely a "sub mode" of YMODEM, discussed in YMODEM.DOC. Compuserve-B is best obtained from Compuserve Information Service, the only place it's supported anyway. I haven't heard of Fmodem (Foo-modem?). Here's the current ZMODEM.DOC: ---------------------- cut here ----------------------------- The ZMODEM Inter Application File Transfer Protocol Chuck Forsberg Omen Technology Inc A overview of this document is available as ZMODEM.OV (in ZMDMOV.ARC) This file may be redistributed without restriction provided the text is not altered. Please distribute as widely as possible. Omen Technology Incorporated The High Reliability Software 17505-V Northwest Sauvie Island Road Portland Oregon 97231 VOICE: 503-621-3406 :VOICE Modem: 503-621-3746 Speed 1200,2400,19200(Telebit PEP) Compuserve:70007,2304 GEnie:CAF UUCP: ...!tektronix!reed!omen!caf Chapter 0 Rev Oct-14-88 Typeset 10-14-88 1 Chapter 0 ZMODEM Protocol 2 1. IIIINNNNTTTTEEEENNNNDDDDEEEEDDDD AAAAUUUUDDDDIIIIEEEENNNNCCCCEEEE This document is intended for telecommunications managers, systems programmers, and others who choose and implement asynchronous file transfer protocols over dial-up networks and related environments. 2. WWWWHHHHYYYY DDDDEEEEVVVVEEEELLLLOOOOPPPP ZZZZMMMMOOOODDDDEEEEMMMM???? Since its development half a decade ago, the Ward Christensen MMMMOOOODDDDEEEEMMMM 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, now called XXXXMMMMOOOODDDDEEEEMMMM. Advances in computing, modems and networking have spread the XMODEM protocol far beyond the micro to micro environment for which it was designed. These application have exposed some weaknesses: o+ The awkward user interface is suitable for computer hobbyists. Multiple commands must be keyboarded to transfer each file. o+ Since commands must be given to both programs, simple menu selections are not possible. o+ The short block length causes throughput to suffer when used with timesharing systems, packet switched networks, satellite circuits, and buffered (error correcting) modems. o+ The 8 bit checksum and unprotected supervison allow undetected errors and disrupted file transfers. o+ Only one file can be sent per command. The file name has to be given twice, first to the sending program and then again to the receiving program. o+ The transmitted file accumulates as many as 127 bytes of garbage. o+ The modification date and other file attributes are lost. o+ XMODEM requires _c_o_m_p_l_e_t_e 8 bit transparency, all 256 codes. XMODEM will not operate over some networks that use ASCII flow control or escape codes. Setting network transparency disables important control functions for the duration of the call. A number of other protocols have been developed over the years, but none have proven satisfactory. o+ Lack of public domain documentation and example programs have kept proprietary protocols such as RRRReeeellllaaaayyyy,,,, BBBBllllaaaasssstttt,,,, DDDDAAAARRRRTTTT,,,, and others tightly bound to the fortunes of their suppliers. These protocols have not benefited from public scrutiny of their design features. Chapter 2 Rev Oct-14-88 Typeset 10-14-88 2 Chapter 2 ZMODEM Protocol 3 o+ Link level protocols such as XXXX....22225555,,,, XXXX....PPPPCCCC,,,, and MMMMNNNNPPPP do not manage application to application file transfers. o+ Link Level protocols do not eliminate end-to-end errors. Interfaces between error-free networks are not necessarily error-free. Sometimes, error-free networks aren't. o+ The KKKKeeeerrrrmmmmiiiitttt protocol was developed to allow file transfers in environments hostile to XMODEM. The performance compromises necessary to accommodate traditional mainframe environments limit Kermit's efficiency. Even with completely transparent channels, Kermit control character quoting limits the efficiency of binary file transfers to about 75 per cent.[1] A number of submodes are used in various Kermit programs, including different methods of transferring binary files. Two Kermit programs will mysteriously fail to operate with each other if the user has not correctly specified these submodes. Kermit Sliding Windows ("SuperKermit") improves throughput over networks at the cost of increased complexity. SuperKermit requires full duplex communications and the ability to check for the presence of characters in the input queue, precluding its implementation on some operating systems. SuperKermit state transitions are encoded in a special language "wart" which requires a C compiler. SuperKermit sends an ACK packet for each data packet of 96 bytes (fewer if control characters are present). This reduces throughput on high speed modems, from 1350 to 177 characters per second in one test. A number of extensions to the XMODEM protocol have been made to improve performance and (in some cases) the user interface. They provide useful improvements in some applications but not in others. XMODEM's unprotected control messages compromise their reliability. Complex proprietary techniques such as CCCCyyyybbbbeeeerrrrnnnneeeettttiiiicccc DDDDaaaattttaaaa RRRReeeeccccoooovvvveeeerrrryyyy((((TTTTMMMM))))[2] improve reliability, but are not universally available. Some of the XMODEM mutant protocols have significant design flaws of their own. o+ XXXXMMMMOOOODDDDEEEEMMMM----kkkk uses 1024 byte blocks to reduce the overhead from transmission delays by 87 per cent compared to XMODEM, but network delays still __________ 1. Some Kermit programs support run length encoding. 2. Unique to DSZ, ZCOMM, Professional-YAM and PowerCom Chapter 2 Rev Oct-14-88 Typeset 10-14-88 3 Chapter 2 ZMODEM Protocol 4 degrade performance. Some networks cannot transmit 1024 byte packets without flow control, which is difficult to apply without impairing the perfect transparency required by XMODEM. XMODEM-k adds garbage to received files. o+ YYYYMMMMOOOODDDDEEEEMMMM sends the file name, file length, and creation date at the beginning of each file, and allows optional 1024 byte blocks for improved throughput. The handling of files that are not a multiple of 1024 or 128 bytes is awkward, especially if the file length is not known in advance, or changes during transmission. The large number of non conforming and substandard programs claiming to support YMODEM further complicates its use. o+ YYYYMMMMOOOODDDDEEEEMMMM----gggg provides efficient batch file transfers, preserving exact file length and file modification date. YMODEM-g is a modification to YMODEM wherein ACKs for data blocks are not used. YMODEM-g is essentially insensitive to network delays. Because it does not support error recovery, YMODEM-g must be used hard wired or with a reliable link level protocol. Successful application at high speed requires cafeful attention to transparent flow control. When YMODEM-g detects a CRC error, data transfers are aborted. YMODEM-g is easy to implement because it closely resembles standard YMODEM-1k. o+ WWWWXXXXMMMMOOOODDDDEEEEMMMM,,,, SSSSEEEEAAAAlllliiiinnnnkkkk,,,, and MMMMEEEEGGGGAAAAlllliiiinnnnkkkk have applied a subset of ZMODEM's techniques to "Classic XMODEM" to improve upon their suppliers' previous offerings. They provide good performance under ideal conditions. Another XMODEM "extension" is protocol cheating, such as Omen Technology's OOOOvvvveeeerrrrTTTThhhhrrrruuuusssstttteeeerrrr((((TTTTMMMM)))) and OOOOvvvveeeerrrrTTTThhhhrrrruuuusssstttteeeerrrr IIIIIIII((((TTTTMMMM)))). These improve XMODEM throughput under some conditions by compromising error recovery. The ZMODEM Protocol corrects the weaknesses described above while maintaining as much of XMODEM/CRC's simplicity and prior art as possible. 3. ZZZZMMMMOOOODDDDEEEEMMMM PPPPrrrroooottttooooccccoooollll DDDDeeeessssiiiiggggnnnn CCCCrrrriiiitttteeeerrrriiiiaaaa The design of a file transfer protocol is an engineering compromise between conflicting requirements: 3.1 EEEEaaaasssseeee ooooffff UUUUsssseeee o+ ZMODEM allows either program to initiate file transfers. o+ The sender can pass commands and/or modifiers to the receiving program. o+ File names need be entered only once. Chapter 3 Rev Oct-14-88 Typeset 10-14-88 4 Chapter 3 ZMODEM Protocol 5 o+ Menu selections are supported. o+ Wild Card names may be used with batch transfers. o+ Minimum keystrokes required to initiate transfers. o+ ZRQINIT frame sent by sending program can trigger automatic downloads. o+ ZMODEM can optionally step down to YMODEM if the other end does not support ZMODEM.[1] 3.2 TTTThhhhrrrroooouuuugggghhhhppppuuuutttt All file transfer protocols make tradeoffs between throughput, reliability, universality, and complexity according to the technology and knowledge base available to their designers. In the design of ZMODEM, three applications deserve special attention. o+ Network applications with significant delays (relative to character transmission time) and low error rate o+ Timesharing and buffered modem applications with significant delays and throughput that is quickly degraded by reverse channel traffic. ZMODEM's economy of reverse channel bandwidth allows modems that dynamically partition bandwidth between the two directions to operate at optimal speeds. Special ZMODEM features allow simple, efficient implementation on a wide variety of timesharing hosts. o+ Traditional direct modem to modem communications with high error rate Unlike Sliding Windows Kermit, ZMODEM is not optimized for optimum throughput when error rate and delays are both high. This tradeoff markedly reduces code complexity and memory requirements. ZMODEM generally provides faster error recovery than network compatible XMODEM implementations. In the absence of network delays, rapid error recovery is possible, much faster than MEGAlink and network compatible versions of YMODEM and XMODEM. File transfers begin immediately regardless of which program is started first, without the 10 second delay associated with XMODEM. __________ 1. Provided the transmission medium accommodates X/YMODEM. Chapter 3 Rev Oct-14-88 Typeset 10-14-88 5 Chapter 3 ZMODEM Protocol 6 3.3 IIIInnnntttteeeeggggrrrriiiittttyyyy aaaannnndddd RRRRoooobbbbuuuussssttttnnnneeeessssssss Once a ZMODEM session is begun, aaaallllllll transactions are protected with 16 or 32 bit CRC.[2] Complex proprietary techniques such as Omen Technology's CCCCyyyybbbbeeeerrrrnnnneeeettttiiiicccc DDDDaaaattttaaaa RRRReeeeccccoooovvvveeeerrrryyyy((((TTTTMMMM))))[3] are not needed for reliable transfers. This complete protection of data and supervisory information accounts for most of ZMODEM's high reliability compared to XMODEM derived protocols including WXMODEM, SEAlink, MEGAlink, etc. An optional 32-bit CRC used as the frame check sequence in ADCCP (ANSI X3.66, also known as FIPS PUB 71 and FED-STD-1003, the U.S. versions of CCITT's X.25) is available. The 32 bit CRC reduces undetected errors by at least five orders of magnitude when properly applied (-1 preset, inversion). A security challenge mechanism guards against "Trojan Horse" messages written to mimic legitimate command or file downloads. 3.4 EEEEaaaasssseeee ooooffff IIIImmmmpppplllleeeemmmmeeeennnnttttaaaattttiiiioooonnnn ZMODEM accommodates a wide variety of systems: o+ Microcomputers that cannot overlap disk and serial i/o o+ Microcomputers that cannot overlap serial send and receive o+ Computers and/or networks requiring XON/XOFF flow control o+ Computers that cannot check the serial input queue for the presence of data without having to wait for the data to arrive. Although ZMODEM provides "hooks" for multiple "threads", ZMODEM is not intended to replace link level protocols such as X.25. ZMODEM accommodates network and timesharing system delays by continuously transmitting data unless the receiver interrupts the sender to request retransmission of garbled data. ZMODEM in effect uses the entire file as a window.[4] Using the entire file as a window simplifies buffer management, avoiding the window overrun failure modes that affect MEGAlink, SuperKermit, and others. __________ 2. Except for the CAN-CAN-CAN-CAN-CAN abort sequence which requires five _s_u_c_c_e_s_s_i_v_e CAN characters. 3. Unique to Professional-YAM, ZCOMM, and PowerCom 4. Streaming strategies are discussed in coming chapters. Chapter 3 Rev Oct-14-88 Typeset 10-14-88 6 Chapter 3 ZMODEM Protocol 7 ZMODEM provides a general purpose application to application file transfer protocol which may be used directly or with with reliable link level protocols such as X.25, MNP, Fastlink, etc. When used with X.25, MNP, Fastlink, etc., ZMODEM detects and corrects errors in the interfaces between error controlled media and the remainder of the communications link. ZMODEM was developed _f_o_r _t_h_e _p_u_b_l_i_c _d_o_m_a_i_n under a Telenet contract. The ZMODEM protocol descriptions and the Unix rz/sz program source code are public domain. No licensing, trademark, or copyright restrictions apply to the use of the protocol, the Unix rz/sz source code and the _Z_M_O_D_E_M name. 4. EEEEVVVVOOOOLLLLUUUUTTTTIIIIOOOONNNN OOOOFFFF ZZZZMMMMOOOODDDDEEEEMMMM In early 1986, Telenet funded a project to develop an improved public domain application to application file transfer protocol. This protocol would alleviate the throughput problems network customers were experiencing with XMODEM and Kermit file transfers. In the beginning, we thought a few modifications to XMODEM would allow high performance over packet switched networks while preserving XMODEM's simplicity. The initial concept would add a block number to the ACK and NAK characters used by XMODEM. The resultant protocol would allow the sender to send more than one block before waiting for a response. But how to add the block number to XMODEM's ACK and NAK? WXMODEM, SEAlink, MEGAlink and some other protocols add binary byte(s) to indicate the block number. Pure binary was unsuitable for ZMODEM because binary code combinations won't pass bidirectionally through some modems, networks and operating systems. Other operating systems may not be able to recognize something coming back[1] unless a break signal or a system dependent code or sequence is present. By the time all this and other problems with the simple ACK/NAK sequences mentioned above were corrected, XMODEM's simple ACK and NACK characters had evolved into a real packet. The Frog was riveting. Managing the window[2] was another problem. Experience gained in __________ 1. Without stopping for a response 2. The WINDOW is the data in transit between sender and receiver. Chapter 4 Rev Oct-14-88 Typeset 10-14-88 7 Chapter 4 ZMODEM Protocol 8 debugging The Source's SuperKermit protocol indicated a window size of about 1000 characters was needed at 1200 bps. High speed modems require a window of 20000 or more characters for full throughput. Much of the SuperKermit's inefficiency, complexity and debugging time centered around its ring buffering and window management. There had to be a better way to get the job done. A sore point with XMODEM and its progeny is error recovery. More to the point, how can the receiver determine whether the sender has responded, or is ready to respond, to a retransmission request? XMODEM attacks the problem by throwing away characters until a certain period of silence. Too short a time allows a spurious pause in output (network or timesharing congestion) to masquerade as error recovery. Too long a timeout devastates throughput, and allows a noisy line to lock up the protocol. SuperKermit solves the problem with a distinct start of packet character (SOH). WXMODEM and ZMODEM use unique character sequences to delineate the start of frames. SEAlink and MEGAlink do not address this problem. A further error recovery problem arises in streaming protocols. How does the receiver know when (or if) the sender has recognized its error signal? Is the next packet the correct response to the error signal? Is it something left over "in the queue"? Or is this new subpacket one of many that will have to be discarded because the sender did not receive the error signal? How long should this continue before sending another error signal? How can the protocol prevent this from degenerating into an argument about mixed signals? SuperKermit uses selective retransmission, so it can accept any good packet it receives. Each time the SuperKermit receiver gets a data packet, it must decide which outstanding packet (if any) it "wants most" to receive, and asks for that one. In practice, complex software "hacks" are needed to attain acceptable robustness.[3] For ZMODEM, we decided to forgo the complexity of SuperKermit's packet assembly scheme and its associated buffer management logic and memory requirements. Another sore point with XMODEM and WXMODEM is the garbage added to files. This was acceptable with the old CP/M files which had no exact length, but not with newer systems such as PC-DOS and Unix. YMODEM uses file length information transmitted in the header block to trim the output file, but this causes data loss when transferring files that grow during a transfer. __________ 3. For example, when SuperKermit encounters certain errors, the _w_n_d_e_s_r function is called to determine the next block to request. A burst of errors generates several wasteful requests to retransmit the same block. Chapter 4 Rev Oct-14-88 Typeset 10-14-88 8 Chapter 4 ZMODEM Protocol 9 In some cases, the file length may be unknown, as when data is obtained from a process. Variable length data subpackets solve both of these problems. Since some characters had to be escaped anyway, there wasn't any point wasting bytes to fill out a fixed packet length or to specify a variable packet length. In ZMODEM, the length of data subpackets is denoted by ending each subpacket with an escape sequence similar to BISYNC and HDLC. The end result is a ZMOEM header containing a "frame type", four bytes of supervisory information, and its own CRC. Data frames consist of a header followed by 1 or more data subpackets. In the absence of transmission errors, an entire file can be sent in one data frame. Since the sending system may be sensitive to numerous control characters or strip parity in the reverse data path, all of the headers sent by the receiver are sent in hex. A common lower level routine receives all headers, allowing the main program logic to deal with headers and data subpackets as objects. With equivalent binary (efficient) and hex (application friendly) frames, the sending program can send an "invitation to receive" sequence to activate the receiver without crashing the remote application with unexpected control characters. Going "back to scratch" in the protocol design presents an opportunity to steal good ideas from many sources and to add a few new ones. From Kermit and UUCP comes the concept of an initial dialog to exchange system parameters. ZMODEM generalizes Compuserve B Protocol's host controlled transfers to single command AutoDownload and command downloading. A Security Challenge discourages password hackers and Trojan Horse authors from abusing ZMODEM's power. We were also keen to the pain and $uffering of legions of telecommunicators whose file transfers have been ruined by communications and timesharing faults. ZMODEM's file transfer recovery and advanced file management are dedicated to these kindred comrades. After ZMODEM had been operational a short time, Earl Hall pointed out the obvious: ZMODEM's user friendly AutoDownload was almost useless if the user must assign transfer options to each of the sending and receiving programs. Now, transfer options may be specified to/by the sending program, which passes them to the receiving program in the ZFILE header. Chapter 5 Rev Oct-14-88 Typeset 10-14-88 9 Chapter 5 ZMODEM Protocol 10 5. RRRROOOOSSSSEEEETTTTTTTTAAAA SSSSTTTTOOOONNNNEEEE Here are some definitions which reflect current vernacular in the computer media. The attempt here is identify the file transfer protocol rather than specific programs. FRAME A ZMODEM frame consists of a header and 0 or more data subpackets. XMODEM refers to the original 1977 file transfer etiquette introduced by Ward Christensen's MODEM2 program. 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's Group" and "TERM II FTP 3". This protocol is supported by most communications programs because it is easy to implement. XMODEM/CRC replaces XMODEM's 1 byte checksum with a two byte Cyclical Redundancy Check (CRC-16), improving error detection. XMODEM-1k Refers to XMODEM-CRC with optional 1024 byte blocks. YMODEM refers to the XMODEM/CRC protocol with batch transmission and optional 1024 byte blocks as described in YMODEM.DOC.[1] 6. ZZZZMMMMOOOODDDDEEEEMMMM RRRREEEEQQQQUUUUIIIIRRRREEEEMMMMEEEENNNNTTTTSSSS ZMODEM requires an 8 bit transfer medium.[1] ZMODEM escapes network control characters to allow operation with packet switched networks. In general, ZMODEM operates over any path that supports XMODEM, and over many that don't. To support full streaming,[2] the transmission path should either assert flow control or pass full speed transmission without loss of data. Otherwise the ZMODEM sender must manage the window size. 6.1 FFFFiiiilllleeee CCCCoooonnnntttteeeennnnttttssss 6.1.1 BBBBiiiinnnnaaaarrrryyyy FFFFiiiilllleeeessss ZMODEM places no constraints on the information content of binary files, except that the number of bits in the file must be a multiple of 8. __________ 1. Available on TeleGodzilla as part of YZMODEM.ZOO 1. The ZMODEM design allows encoded packets for less transparent media. 2. With XOFF and XON, or out of band flow control such as X.25 or CTS Chapter 6 Rev Oct-14-88 Typeset 10-14-88 10 Chapter 6 ZMODEM Protocol 11 6.1.2 TTTTeeeexxxxtttt FFFFiiiilllleeeessss Since ZMODEM is used to transfer files between different types of computer systems, text files must meet minimum requirements if they are to be readable on a wide variety of systems and environments. Text lines consist of printing ASCII characters, spaces, tabs, and backspaces. 6.1.2.1 AAAASSSSCCCCIIIIIIII EEEEnnnndddd ooooffff LLLLiiiinnnneeee The ASCII code definition allows text lines terminated by a CR/LF (015, 012) sequence, or by a NL (012) character. Lines logically terminated by a lone CR (013) are not ASCII text. A CR (013) without a linefeed implies overprinting, and is not acceptable as a logical line separator. Overprinted lines should print all important characters in the last pass to allow CRT displays to display meaningful text. Overstruck characters may be generated by backspacing or by overprinting the line with CR (015) not followed by LF. Overstruck characters generated with backspaces should be sent with the most important character last to accommodate CRT displays that cannot overstrike. The sending program may use the ZZZZCCCCNNNNLLLL bit to force the receiving program to convert the received end of line to its local end of line convention.[3] __________ 3. Files that have been translated in such a way as to modify their length cannot be updated with the ZZZZCCCCRRRREEEECCCCOOOOVVVV Conversion Option. Chapter 6 Rev Oct-14-88 Typeset 10-14-88 11 Chapter 6 ZMODEM Protocol 12 7. ZZZZMMMMOOOODDDDEEEEMMMM BBBBAAAASSSSIIIICCCCSSSS 7.1 PPPPaaaacccckkkkeeeettttiiiizzzzaaaattttiiiioooonnnn ZMODEM frames differ somewhat from XMODEM blocks. XMODEM blocks are not used for the following reasons: o+ Block numbers are limited to 256 o+ No provision for variable length blocks o+ Line hits corrupt protocol signals, causing failed file transfers. In particular, modem errors sometimes generate false block numbers, false EOTs and false ACKs. False ACKs are the most troublesome as they cause the sender to lose synchronization with the receiver. State of the art programs such as Professional-YAM and ZCOMM overcome some of these weaknesses with clever proprietary code, but a stronger protocol is desired. o+ It is difficult to determine the beginning and ends of XMODEM blocks when line hits cause a loss of synchronization. This precludes rapid error recovery. 7.2 LLLLiiiinnnnkkkk EEEEssssccccaaaappppeeee EEEEnnnnccccooooddddiiiinnnngggg ZMODEM achieves data transparency by extending the 8 bit character set (256 codes) with escape sequences based on the ZMODEM data link escape character ZDLE.[1] Link Escape coding permits variable length data subpackets without the overhead of a separate byte count. It allows the beginning of frames to be detected without special timing techniques, facilitating rapid error recovery. Link Escape coding does add some overhead. The worst case, a file consisting entirely of escaped characters, would incur a 50% overhead. The ZDLE character is special. ZDLE represents a control sequence of some sort. If a ZDLE character appears in binary data, it is prefixed with ZDLE, then sent as ZDLEE. The value for ZDLE is octal 030 (ASCII CAN). This particular value was chosen to allow a string of 5 consecutive CAN characters to abort a ZMODEM __________ 1. This and other constants are defined in the _z_m_o_d_e_m._h include file. Please note that constants with a leading 0 are octal constants in C. Chapter 7 Rev Oct-14-88 Typeset 10-14-88 12 Chapter 7 ZMODEM Protocol 13 session, compatible with YMODEM session abort. Since CAN is not used in normal terminal operations, interactive applications and communications programs can monitor the data flow for ZDLE. The following characters can be scanned to detect the ZRQINIT header, the invitation to automatically download commands or files. Receipt of five successive CAN characters will abort a ZMODEM session. Eight CAN characters are sent. The receiving program decodes any sequence of ZDLE followed by a byte with bit 6 set and bit 5 reset (upper case letter, either parity) to the equivalent control character by inverting bit 6. This allows the transmitter to escape any control character that cannot be sent by the communications medium. In addition, the receiver recognizes escapes for 0177 and 0377 should these characters need to be escaped. ZMODEM software escapes ZDLE, 020, 0220, 021, 0221, 023, and 0223. If preceded by 0100 or 0300 (@), 015 and 0215 are also escaped to protect the Telenet command escape CR-@-CR. The receiver ignores 021, 0221, 023, and 0223 characters in the data stream. The ZMODEM routines in zm.c accept an option to escape all control characters, to allow operation with less transparent networks. This option can be given to either the sending or receiving program. 7.3 HHHHeeeeaaaaddddeeeerrrr All ZMODEM frames begin with a header which may be sent in binary or HEX form. ZMODEM uses a single routine to recognize binary and hex headers. Either form of the header contains the same raw information: o+ A type byte[2] [3] o+ Four bytes of data indicating flags and/or numeric quantities depending on the frame type __________ 2. The frame types are cardinal numbers beginning with 0 to minimize state transition table memory requirements. 3. Future extensions to ZMODEM may use the high order bits of the type byte to indicate thread selection. Chapter 7 Rev Oct-14-88 Typeset 10-14-88 13 Chapter 7 ZMODEM Protocol 14 FFFFiiiigggguuuurrrreeee 1111.... Order of Bytes in Header TYPE: frame type F0: Flags least significant byte P0: file Position least significant P3: file Position most significant TYPE F3 F2 F1 F0 ------------------- TYPE P0 P1 P2 P3 7.3.1 11116666 BBBBiiiitttt CCCCRRRRCCCC BBBBiiiinnnnaaaarrrryyyy HHHHeeeeaaaaddddeeeerrrr A binary header is sent by the sending program to the receiving program. ZDLE encoding accommodates XON/XOFF flow control. A binary header begins with the sequence ZPAD, ZDLE, ZBIN. The frame type byte is ZDLE encoded. The four position/flags bytes are ZDLE encoded. A two byte CRC of the frame type and position/flag bytes is ZDLE encoded. 0 or more binary data subpackets with 16 bit CRC will follow depending on the frame type. The function _z_s_b_h_d_r transmits a binary header. The function _z_g_e_t_h_d_r receives a binary or hex header. FFFFiiiigggguuuurrrreeee 2222.... 16 Bit CRC Binary Header * ZDLE A TYPE F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2 7.3.2 33332222 BBBBiiiitttt CCCCRRRRCCCC BBBBiiiinnnnaaaarrrryyyy HHHHeeeeaaaaddddeeeerrrr A "32 bit CRC" Binary header is similar to a Binary Header, except the ZZZZBBBBIIIINNNN (A) character is replaced by a ZZZZBBBBIIIINNNN33332222 (C) character, and four characters of CRC are sent. 0 or more binary data subpackets with 32 bit CRC will follow depending on the frame type. The common variable _T_x_f_c_s_3_2 may be set TRUE for 32 bit CRC iff the receiver indicates the capability with the CCCCAAAANNNNFFFFCCCC33332222 bit. The zgethdr, zsdata and zrdata functions automatically adjust to the type of Frame Check Sequence being used. FFFFiiiigggguuuurrrreeee 3333.... 32 Bit CRC Binary Header * ZDLE C TYPE F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2 CRC-3 CRC-4 7.3.3 HHHHEEEEXXXX HHHHeeeeaaaaddddeeeerrrr The receiver sends responses in hex headers. The sender also uses hex headers when they are not followed by binary data subpackets. Chapter 7 Rev Oct-14-88 Typeset 10-14-88 14 Chapter 7 ZMODEM Protocol 15 Hex encoding protects the reverse channel from random control characters. The hex header receiving routine ignores parity. Use of Kermit style encoding for control and paritied characters was considered and rejected because of increased possibility of interacting with some timesharing systems' line edit functions. Use of HEX headers from the receiving program allows control characters to be used to interrupt the sender when errors are detected. A HEX header may be used in place of a binary header wherever convenient. If a data packet follows a HEX header, it is protected with CRC-16. A hex header begins with the sequence ZPAD, ZPAD, ZDLE, ZHEX. The _z_g_e_t_h_d_r routine synchronizes with the ZPAD-ZDLE sequence. The extra ZPAD character allows the sending program to detect an asynchronous header (indicating an error condition) and then call _z_g_e_t_h_d_r to receive the header. The type byte, the four position/flag bytes, and the 16 bit CRC thereof are sent in hex using the character set 01234567890abcdef. Upper case hex digits are not allowed; they false trigger XMODEM and YMODEM programs. Since this form of hex encoding detects many patterns of errors, especially missing characters, a hex header with 32 bit CRC has not been defined. A carriage return and line feed are sent with HEX headers. The receive routine expects to see at least one of these characters, two if the first is CR. The CR/LF aids debugging from printouts, and helps overcome certain operating system related problems. An XON character is appended to all HEX packets except ZACK and ZFIN. The XON releases the sender from spurious XOFF flow control characters generated by line noise, a common occurrence. XON is not sent after ZACK headers to protect flow control in streaming situations. XON is not sent after a ZFIN header to allow clean session cleanup. 0 or more data subpackets will follow depending on the frame type. The function _z_s_h_h_d_r sends a hex header. FFFFiiiigggguuuurrrreeee 4444.... HEX Header * * ZDLE B TYPE F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2 CR LF XON (TYPE, F3...F0, CRC-1, and CRC-2 are each sent as two hex digits.) Chapter 7 Rev Oct-14-88 Typeset 10-14-88 15 Chapter 7 ZMODEM Protocol 16 7.4 BBBBiiiinnnnaaaarrrryyyy DDDDaaaattttaaaa SSSSuuuubbbbppppaaaacccckkkkeeeettttssss Binary data subpackets immediately follow the associated binary header packet. A binary data packet contains 0 to 1024 bytes of data. Recommended length values are 256 bytes below 2400 bps, 512 at 2400 bps, and 1024 above 4800 bps or when the data link is known to be relatively error free.[4] No padding is used with binary data subpackets. The data bytes are ZDLE encoded and transmitted. A ZDLE and frameend are then sent, followed by two or four ZDLE encoded CRC bytes. The CRC accumulates the data bytes and frameend. The function _z_s_d_a_t_a sends a data subpacket. The function _z_r_d_a_t_a receives a data subpacket. 7.5 AAAASSSSCCCCIIIIIIII EEEEnnnnccccooooddddeeeedddd DDDDaaaattttaaaa SSSSuuuubbbbppppaaaacccckkkkeeeetttt The format of ASCII Encoded data subpackets is not currently specified. These could be used for server commands, or main transfers in 7 bit environments. 8. PPPPRRRROOOOTTTTOOOOCCCCOOOOLLLL TTTTRRRRAAAANNNNSSSSAAAACCCCTTTTIIIIOOOONNNN OOOOVVVVEEEERRRRVVVVIIIIEEEEWWWW As with the XMODEM recommendation, ZMODEM timing is receiver driven. The transmitter should not time out at all, except to abort the program if no headers are received for an extended period of time, say one minute.[1] 8.1 SSSSeeeessssssssiiiioooonnnn SSSSttttaaaarrrrttttuuuupppp To start a ZMODEM file transfer session, the sending program is called with the names of the desired file(s) and option(s). The sending program may send the string "rz\r" to invoke the receiving program from a possible command mode. The "rz" followed by carriage return activates a ZMODEM receive program or command if it were not already active. The sender may then display a message intended for human consumption, such __________ 4. Strategies for adjusting the subpacket length for optimal results based on real time error rates are still evolving. Shorter subpackets speed error detection but increase protocol overhead slightly. 1. Special considerations apply when sending commands. Chapter 8 Rev Oct-14-88 Typeset 10-14-88 16 Chapter 8 ZMODEM Protocol 17 as a list of the files requested, etc. Then the sender may send a ZZZZRRRRQQQQIIIINNNNIIIITTTT header. The ZZZZRRRRQQQQIIIINNNNIIIITTTT header causes a previously started receive program to send its ZZZZRRRRIIIINNNNIIIITTTT header without delay. In an interactive or conversational mode, the receiving application may monitor the data stream for ZDLE. The following characters may be scanned for BBBB00000000 indicating a ZRQINIT header, a command to download a command or data. The sending program awaits a command from the receiving program to start file transfers. If a "C", "G", or NAK is received, an XMODEM or YMODEM file transfer is indicated, and file transfer(s) use the YMODEM protocol. Note: With ZMODEM and YMODEM, the sending program provides the file name, but not with XMODEM. In case of garbled data, the sending program can repeat the invitation to receive a number of times until a session starts. When the ZMODEM receive program starts, it immediately sends a ZZZZRRRRIIIINNNNIIIITTTT header to initiate ZMODEM file transfers, or a ZZZZCCCCHHHHAAAALLLLLLLLEEEENNNNGGGGEEEE header to verify the sending program. The receive program resends its header at _r_e_s_p_o_n_s_e _t_i_m_e (default 10 second) intervals for a suitable period of time (40 seconds total) before falling back to YMODEM protocol. If the receiving program receives a ZZZZRRRRQQQQIIIINNNNIIIITTTT header, it resends the ZZZZRRRRIIIINNNNIIIITTTT header. If the sending program receives the ZZZZCCCCHHHHAAAALLLLLLLLEEEENNNNGGGGEEEE header, it places the data in ZP0...ZP3 in an answering ZZZZAAAACCCCKKKK header. If the receiving program receives a ZZZZRRRRIIIINNNNIIIITTTT header, it is an echo indicating that the sending program is not operational. Eventually the sending program correctly receives the ZZZZRRRRIIIINNNNIIIITTTT header. The sender may then send an optional ZZZZSSSSIIIINNNNIIIITTTT frame to define the receiving program's AAAAttttttttnnnn sequence, or to specify complete control character escaping.[2] If the ZSINIT header specifies ESCCTL or ESC8, a HEX header is used, and the receiver activates the specified ESC modes before reading the following data subpacket. The receiver sends a ZZZZAAAACCCCKKKK header in response, containing either the serial __________ 2. If the receiver specifies the same or higher level of escaping, the ZSINIT frame need not be sent unless an Attn sequence is needed. Chapter 8 Rev Oct-14-88 Typeset 10-14-88 17 Chapter 8 ZMODEM Protocol 18 number of the receiving program, or 0. 8.2 FFFFiiiilllleeee TTTTrrrraaaannnnssssmmmmiiiissssssssiiiioooonnnn The sender then sends a ZZZZFFFFIIIILLLLEEEE header with ZMODEM Conversion, Management, and Transport options[3] followed by a ZCRCW data subpacket containing the file name, file length, modification date, and other information identical to that used by YMODEM Batch. The receiver examines the file name, length, and date information provided by the sender in the context of the specified transfer options, the current state of its file system(s), and local security requirements. The receiving program should insure the pathname and options are compatible with its operating environment and local security requirements. The receiver may respond with a ZZZZSSSSKKKKIIIIPPPP header, which makes the sender proceed to the next file (if any) in the batch. The receiver has a file with the same name and length, may respond with a ZZZZCCCCRRRRCCCC header with a byte count, which requires the sender to perform a 32 bit CRC on the specified number of bytes in the file and transmit the complement of the CRC in an answering ZZZZCCCCRRRRCCCC header.[4] The receiver uses this information to determine whether to accept the file or skip it. This sequence may be triggered by the ZMCRC Management Option. A ZZZZRRRRPPPPOOOOSSSS header from the receiver initiates transmission of the file data starting at the offset in the file specified in the ZZZZRRRRPPPPOOOOSSSS header. Normally the receiver specifies the data transfer to begin begin at offset 0 in the file. The receiver may start the transfer further down in the file. This allows a file transfer interrupted by a loss or carrier or system crash to be completed on the next connection without requiring the entire file to be retransmitted.[5] If downloading a file from a timesharing system that becomes sluggish, the transfer can be interrupted and resumed later with no loss of data. The sender sends a ZZZZDDDDAAAATTTTAAAA binary header (with file position) followed by __________ 3. See below, under ZFILE header type. 4. The crc is initialized to 0xFFFFFFFF. A byte count of 0 implies the entire file. 5. This does not apply to files that have been translated. Chapter 8 Rev Oct-14-88 Typeset 10-14-88 18 Chapter 8 ZMODEM Protocol 19 one or more data subpackets. The receiver compares the file position in the ZZZZDDDDAAAATTTTAAAA header with the number of characters successfully received to the file. If they do not agree, a ZZZZRRRRPPPPOOOOSSSS error response is generated to force the sender to the right position within the file.[6] A data subpacket terminated by ZZZZCCCCRRRRCCCCGGGG and CRC does not elicit a response unless an error is detected; more data subpacket(s) follow immediately. ZZZZCCCCRRRRCCCCQQQQ data subpackets expect a ZZZZAAAACCCCKKKK response with the receiver's file offset if no error, otherwise a ZZZZRRRRPPPPOOOOSSSS response with the last good file offset. Another data subpacket continues immediately. ZZZZCCCCRRRRCCCCQQQQ subpackets are not used if the receiver does not indicate FDX ability with the CCCCAAAANNNNFFFFDDDDXXXX bit. ZZZZCCCCRRRRCCCCWWWW data subpackets expect a response before the next frame is sent. If the receiver does not indicate overlapped I/O capability with the CCCCAAAANNNNOOOOVVVVIIIIOOOO bit, or sets a buffer size, the sender uses the ZZZZCCCCRRRRCCCCWWWW to allow the receiver to write its buffer before sending more data. A zero length data frame may be used as an idle subpacket to prevent the receiver from timing out in case data is not immediately available to the sender. In the absence of fatal error, the sender eventually encounters end of file. If the end of file is encountered within a frame, the frame is closed with a ZZZZCCCCRRRRCCCCEEEE data subpacket which does not elicit a response except in case of error. The sender sends a ZZZZEEEEOOOOFFFF header with the file ending offset equal to the number of characters in the file. The receiver compares this number with the number of characters received. If the receiver has received all of the file, it closes the file. If the file close was satisfactory, the receiver responds with ZZZZRRRRIIIINNNNIIIITTTT. If the receiver has not received all the bytes of the file, the receiver ignores the ZEOF because a new ZDATA is coming. If the receiver cannot properly close the file, a ZZZZFFFFEEEERRRRRRRR header is sent. __________ 6. If the ZMSPARS option is used, the receiver instead seeks to the position given in the ZDATA header. Chapter 8 Rev Oct-14-88 Typeset 10-14-88 19 Chapter 8 ZMODEM Protocol 20 After all files are processed, any further protocol errors should not prevent the sending program from returning with a success status. 8.3 SSSSeeeessssssssiiiioooonnnn CCCClllleeeeaaaannnnuuuupppp The sender closes the session with a ZZZZFFFFIIIINNNN header. The receiver acknowledges this with its own ZZZZFFFFIIIINNNN header. When the sender receives the acknowledging header, it sends two characters, "OO" (Over and Out) and exits to the operating system or application that invoked it. The receiver waits briefly for the "O" characters, then exits whether they were received or not. 8.4 SSSSeeeessssssssiiiioooonnnn AAAAbbbboooorrrrtttt SSSSeeeeqqqquuuueeeennnncccceeee If the receiver is receiving data in streaming mode, the AAAAttttttttnnnn sequence is executed to interrupt data transmission before the Cancel sequence is sent. The Cancel sequence consists of eight CAN characters and ten backspace characters. ZMODEM only requires five Cancel characters, the other three are "insurance". The trailing backspace characters attempt to erase the effects of the CAN characters if they are received by a command interpreter. static char canistr[] = { 24,24,24,24,24,24,24,24,8,8,8,8,8,8,8,8,8,8,0 }; Chapter 8 Rev Oct-14-88 Typeset 10-14-88 20 Chapter 8 ZMODEM Protocol 21 9. SSSSTTTTRRRREEEEAAAAMMMMIIIINNNNGGGG TTTTEEEECCCCHHHHNNNNIIIIQQQQUUUUEEEESSSS //// EEEERRRRRRRROOOORRRR RRRREEEECCCCOOOOVVVVEEEERRRRYYYY It is a fact of life that no single method of streaming is applicable to a majority of today's computing and telecommunications environments. ZMODEM provides several data streaming methods selected according to the limitations of the sending environment, receiving environment, and transmission channel(s). 9.1 FFFFuuuullllllll SSSSttttrrrreeeeaaaammmmiiiinnnngggg wwwwiiiitttthhhh SSSSaaaammmmpppplllliiiinnnngggg If the receiver can overlap serial I/O with disk I/O, and if the sender can sample the reverse channel for the presence of data without having to wait, full streaming can be used with no AAAAttttttttnnnn sequence required. The sender begins data transmission with a ZZZZDDDDAAAATTTTAAAA header and continuous ZZZZCCCCRRRRCCCCGGGG data subpackets. When the receiver detects an error, it executes the AAAAttttttttnnnn sequence and then sends a ZZZZRRRRPPPPOOOOSSSS header with the correct position within the file. At the end of each transmitted data subpacket, the sender checks for the presence of an error header from the receiver. To do this, the sender samples the reverse data stream for the presence of either a ZPAD or CAN character.[1] Flow control characters (if present) are acted upon. Other characters (indicating line noise) increment a counter which is reset whenever the sender waits for a header from the receiver. If the counter overflows, the sender sends the next data subpacket as ZCRCW, and waits for a response. ZPAD indicates some sort of error header from the receiver. A CAN suggests the user is attempting to "stop the bubble machine" by keyboarding CAN characters. If one of these characters is seen, an empty ZCRCE data subpacket is sent. Normally, the receiver will have sent an ZRPOS or other error header, which will force the sender to resume transmission at a different address, or take other action. In the unlikely event the ZPAD or CAN character was spurious, the receiver will time out and send a ZRPOS header.[2] Then the receiver's response header is read and acted upon.[3] __________ 1. The call to rdchk() in sssszzzz....cccc performs this function. 2. The obvious choice of ZCRCW packet, which would trigger an ZACK from the receiver, is not used because multiple in transit frames could result if the channel has a long propagation delay. 3. The call to getinsync() in sssszzzz....cccc performs this function. Chapter 9 Rev Oct-14-88 Typeset 10-14-88 21 Chapter 9 ZMODEM Protocol 22 A ZZZZRRRRPPPPOOOOSSSS header resets the sender's file offset to the correct position. If possible, the sender should purge its output buffers and/or networks of all unprocessed output data, to minimize the amount of unwanted data the receiver must discard before receiving data starting at the correct file offset. The next transmitted data frame should be a ZCRCW frame followed by a wait to guarantee complete flushing of the network's memory. If the receiver gets a ZZZZAAAACCCCKKKK header with an address that disagrees with the sender address, it is ignored, and the sender waits for another header. A ZZZZFFFFIIIINNNN, ZZZZAAAABBBBOOOORRRRTTTT, or TTTTIIIIMMMMEEEEOOOOUUUUTTTT terminates the session; a ZZZZSSSSKKKKIIIIPPPP terminates the processing of this file. The reverse channel is then sampled for the presence of another header from the receiver.[4] if one is detected, the getinsync() function is again called to read another error header. Otherwise, transmission resumes at the (possibly reset) file offset with a ZZZZDDDDAAAATTTTAAAA header followed by data subpackets. 9.1.1 WWWWiiiinnnnddddoooowwww MMMMaaaannnnaaaaggggeeeemmmmeeeennnntttt When sending data through a network, some nodes of the network store data while it is transferred to the receiver. 7000 bytes and more of transient storage have been observed. Such a large amount of storage causes the transmitter to "get ahead" of the reciever. This can be fatal with MEGAlink and other protocols that depend on timely notification of errors from the receiver. This condition is not fatal with ZMODEM, but it does slow error recovery. To manage the window size, the sending program uses ZCRCQ data subpackets to trigger ZACK headers from the receiver. The returning ZACK headers inform the sender of the receiver's progress. When the window size (current transmitter file offset - last reported receiver file offset) exceeds a specified value, the sender waits for a ZACK[5] packet with a receiver file offset that reduces the window size. Unix _s_z versions beginning with May 9 1987 control the window size with the "-w N" option, where N is the maximum window size. Pro-YAM, ZCOMM and DSZ versions beginning with May 9 1987 control the window size with "zmodem pwN". This is compatible with previous versions of these programs.[6] __________ 4. If sampling is possible. 5. ZRPOS and other error packets are handled normally. 6. When used with modems or networks that simultaneously assert flow Chapter 9 Rev Oct-14-88 Typeset 10-14-88 22 Chapter 9 ZMODEM Protocol 23 9.2 FFFFuuuullllllll SSSSttttrrrreeeeaaaammmmiiiinnnngggg wwwwiiiitttthhhh RRRReeeevvvveeeerrrrsssseeee IIIInnnntttteeeerrrrrrrruuuupppptttt The above method cannot be used if the reverse data stream cannot be sampled without entering an I/O wait. An alternate method is to instruct the receiver to interrupt the sending program when an error is detected. The receiver can interrupt the sender with a control character, break signal, or combination thereof, as specified in the AAAAttttttttnnnn sequence. After executing the AAAAttttttttnnnn sequence, the receiver sends a hex ZZZZRRRRPPPPOOOOSSSS header to force the sender to resend the lost data. When the sending program responds to this interrupt, it reads a HEX header (normally ZRPOS) from the receiver and takes the action described in the previous section. The Unix sssszzzz....cccc program uses a setjmp/longjmp call to catch the interrupt generated by the AAAAttttttttnnnn sequence. Catching the interrupt activates the getinsync() function to read the receiver's error header and take appropriate action. When compiled for standard SYSTEM III/V Unix, sssszzzz....cccc uses an AAAAttttttttnnnn sequence of Ctrl-C followed by a 1 second pause to interrupt the sender, then give the sender (Unix) time to prepare for the receiver's error header. 9.3 FFFFuuuullllllll SSSSttttrrrreeeeaaaammmmiiiinnnngggg wwwwiiiitttthhhh SSSSlllliiiiddddiiiinnnngggg WWWWiiiinnnnddddoooowwww If none of the above methods is applicable, hope is not yet lost. If the sender can buffer responses from the receiver, the sender can use ZCRCQ data subpackets to get ACKs from the receiver without interrupting the transmission of data. After a sufficient number of ZCRCQ data subpackets have been sent, the sender can read one of the headers that should have arrived in its receive interrupt buffer. A problem with this method is the possibility of wasting an excessive amount of time responding to the receiver's error header. It may be possible to program the receiver's AAAAttttttttnnnn sequence to flush the sender's interrupt buffer before sending the ZRPOS header. __________________________________________________________________________ control with XON and XOFF characters aaaannnndddd pass XON characters that violate flow control, the receiving program should have a revision date of May 9 or later. Chapter 9 Rev Oct-14-88 Typeset 10-14-88 23 Chapter 9 ZMODEM Protocol 24 9.4 FFFFuuuullllllll SSSSttttrrrreeeeaaaammmmiiiinnnngggg oooovvvveeeerrrr EEEErrrrrrrroooorrrr FFFFrrrreeeeeeee CCCChhhhaaaannnnnnnneeeellllssss File transfer protocols predicated on the existence of an error free end to end communications channel have been proposed from time to time. Such channels have proven to be more readily available in theory than in actuality. The frequency of undetected errors increases when modem scramblers have more bits than the error detecting CRC. A ZMODEM sender assuming an error free channel with end to end flow control can send the entire file in one frame without any checking of the reverse stream. If this channel is completely transparent, only ZDLE need be escaped. The resulting protocol overhead for average long files is less than one per cent.[7] 9.5 SSSSeeeeggggmmmmeeeennnntttteeeedddd SSSSttttrrrreeeeaaaammmmiiiinnnngggg If the receiver cannot overlap serial and disk I/O, it uses the ZZZZRRRRIIIINNNNIIIITTTT frame to specify a buffer length which the sender will not overflow. The sending program sends a ZZZZCCCCRRRRCCCCWWWW data subpacket and waits for a ZZZZAAAACCCCKKKK header before sending the next segment of the file. If the sending program supports reverse data stream sampling or interrupt, error recovery will be faster (on average) than a protocol (such as YMODEM) that sends large blocks. A sufficiently large receiving buffer allows throughput to closely approach that of full streaming. For example, 16kb segmented streaming adds about 3 per cent to full streaming ZMODEM file transfer times when the round trip delay is five seconds. 10. AAAATTTTTTTTEEEENNNNTTTTIIIIOOOONNNN SSSSEEEEQQQQUUUUEEEENNNNCCCCEEEE The receiving program sends the AAAAttttttttnnnn sequence whenever it detects an error and needs to interrupt the sending program. The default AAAAttttttttnnnn string value is empty (no Attn sequence). The receiving program resets Attn to the empty default before each transfer session. The sender specifies the Attn sequence in its optional ZSINIT frame. The AAAAttttttttnnnn string is terminated with a null. __________ 7. One in 256 for escaping ZDLE, about two (four if 32 bit CRC is used) in 1024 for data subpacket CRC's Chapter 10 Rev Oct-14-88 Typeset 10-14-88 24 Chapter 10 ZMODEM Protocol 25 Two meta-characters perform special functions: o+ \335 (octal) Send a break signal o+ \336 (octal) Pause one second 11. FFFFRRRRAAAAMMMMEEEE TTTTYYYYPPPPEEEESSSS The numeric values for the values shown in boldface are given in _z_m_o_d_e_m._h. Unused bits and unused bytes in the header (ZP0...ZP3) are set to 0. 11.1 ZZZZRRRRQQQQIIIINNNNIIIITTTT Sent by the sending program, to trigger the receiving program to send its ZRINIT header. This avoids the aggravating startup delay associated with XMODEM and Kermit transfers. The sending program may repeat the receive invitation (including ZRQINIT) if a response is not obtained at first. ZF0 contains ZCOMMAND if the program is attempting to send a command, 0 otherwise. 11.2 ZZZZRRRRIIIINNNNIIIITTTT Sent by the receiving program. ZF0 and ZF1 contain the bitwise or of the receiver capability flags: #define CANCRY 8 /* Receiver can decrypt */ #define CANFDX 01 /* Rx can send and receive true FDX */ #define CANOVIO 02 /* Rx can receive data during disk I/O */ #define CANBRK 04 /* Rx can send a break signal */ #define CANCRY 010 /* Receiver can decrypt */ #define CANLZW 020 /* Receiver can uncompress */ #define CANFC32 040 /* Receiver can use 32 bit Frame Check */ #define ESCCTL 0100 /* Receiver expects ctl chars to be escaped */ #define ESC8 0200 /* Receiver expects 8th bit to be escaped */ ZP0 and ZP1 contain the size of the receiver's buffer in bytes, or 0 if nonstop I/O is allowed. 11.3 ZZZZSSSSIIIINNNNIIIITTTT The Sender sends flags followed by a binary data subpacket terminated with ZZZZCCCCRRRRCCCCWWWW. /* Bit Masks for ZSINIT flags byte ZF0 */ #define TESCCTL 0100 /* Transmitter expects ctl chars to be escaped */ #define TESC8 0200 /* Transmitter expects 8th bit to be escaped Chapter 11 Rev Oct-14-88 Typeset 10-14-88 25 Chapter 11 ZMODEM Protocol 26 */ The data subpacket contains the null terminated AAAAttttttttnnnn sequence, maximum length 32 bytes including the terminating null. 11.4 ZZZZAAAACCCCKKKK Acknowledgment to a ZZZZSSSSIIIINNNNIIIITTTT frame, ZZZZCCCCHHHHAAAALLLLLLLLEEEENNNNGGGGEEEE header, ZZZZCCCCRRRRCCCCQQQQ or ZZZZCCCCRRRRCCCCWWWW data subpacket. ZP0 to ZP3 contain file offset. The response to ZCHALLENGE contains the same 32 bit number received in the ZCHALLENGE header. 11.5 ZZZZFFFFIIIILLLLEEEE This frame denotes the beginning of a file transmission attempt. ZF0, ZF1, and ZF2 may contain options. A value of 0 in each of these bytes implies no special treatment. Options specified to the receiver override options specified to the sender with the exception of ZZZZCCCCBBBBIIIINNNN. A ZZZZCCCCBBBBIIIINNNN from the sender overrides any other Conversion Option given to the receiver except ZCRESUM. A ZZZZCCCCBBBBIIIINNNN from the receiver overrides any other Conversion Option sent by the sender. 11.5.1 ZZZZFFFF0000:::: CCCCoooonnnnvvvveeeerrrrssssiiiioooonnnn OOOOppppttttiiiioooonnnn If the receiver does not recognize the Conversion Option, an application dependent default conversion may apply. ZZZZCCCCBBBBIIIINNNN "Binary" transfer - inhibit conversion unconditionally ZZZZCCCCNNNNLLLL Convert received end of line to local end of line convention. The supported end of line conventions are CR/LF (most ASCII based operating systems except Unix and Macintosh), and NL (Unix). Either of these two end of line conventions meet the permissible ASCII definitions for Carriage Return and Line Feed/New Line. Neither the ASCII code nor ZMODEM ZCNL encompass lines separated only by carriage returns. Other processing appropriate to ASCII text files and the local operating system may also be applied by the receiver.[1] ZZZZCCCCRRRREEEECCCCOOOOVVVV Recover/Resume interrupted file transfer. ZCREVOV is also useful for updating a remote copy of a file that grows without resending of old data. If the destination file exists and is no longer than the source, append to the destination file and start transfer at the offset __________ 1. Filtering RUBOUT, NULL, Ctrl-Z, etc. Chapter 11 Rev Oct-14-88 Typeset 10-14-88 26 Chapter 11 ZMODEM Protocol 27 corresponding to the receiver's end of file. This option does not apply if the source file is shorter. Files that have been converted (e.g., ZCNL) or subject to a single ended Transport Option cannot have their transfers recovered. 11.5.2 ZZZZFFFF1111:::: MMMMaaaannnnaaaaggggeeeemmmmeeeennnntttt OOOOppppttttiiiioooonnnn If the receiver does not recognize the Management Option, the file should be transferred normally. The ZZZZMMMMSSSSKKKKNNNNOOOOLLLLOOOOCCCC bit instructs the receiver to bypass the current file if the receiver does not have a file with the same name. Five bits (defined by ZZZZMMMMMMMMAAAASSSSKKKK) define the following set of mutually exclusive management options. ZZZZMMMMNNNNEEEEWWWWLLLL Transfer file if destination file absent. Otherwise, transfer file overwriting destination if the source file is newer or longer. ZZZZMMMMCCCCRRRRCCCC Compare the source and destination files. Transfer if file lengths or file polynomials differ. ZZZZMMMMAAAAPPPPNNNNDDDD Append source file contents to the end of the existing destination file (if any). ZZZZMMMMCCCCLLLLOOOOBBBB Replace existing destination file (if any). ZZZZMMMMDDDDIIIIFFFFFFFF Transfer file if destination file absent. Otherwise, transfer file overwriting destination if files have different lengths or dates. ZZZZMMMMPPPPRRRROOOOTTTT Protect destination file by transferring file only if the destination file is absent. ZZZZMMMMNNNNEEEEWWWW Transfer file if destination file absent. Otherwise, transfer file overwriting destination if the source file is newer. 11.5.3 ZZZZFFFF2222:::: TTTTrrrraaaannnnssssppppoooorrrrtttt OOOOppppttttiiiioooonnnn If the receiver does not implement the particular transport option, the file is copied without conversion for later processing. ZZZZTTTTLLLLZZZZWWWW Lempel-Ziv compression. Transmitted data will be identical to that produced by ccccoooommmmpppprrrreeeessssssss 4444....0000 operating on a computer with VAX byte ordering, using 12 bit encoding. Chapter 11 Rev Oct-14-88 Typeset 10-14-88 27 Chapter 11 ZMODEM Protocol 28 ZZZZTTTTCCCCRRRRYYYYPPPPTTTT Encryption. An initial null terminated string identifies the key. Details to be determined. ZZZZTTTTRRRRLLLLEEEE Run Length encoding, Details to be determined. A ZZZZCCCCRRRRCCCCWWWW data subpacket follows with file name, file length, modification date, and other information described in a later chapter. 11.5.4 ZZZZFFFF3333:::: EEEExxxxtttteeeennnnddddeeeedddd OOOOppppttttiiiioooonnnnssss The Extended Options are bit encoded. ZZZZTTTTSSSSPPPPAAAARRRRSSSS Special processing for sparse files, or sender managed selective retransmission. Each file segment is transmitted as a separate frame, where the frames are not necessarily contiguous. The sender should end each segment with a ZCRCW data subpacket and process the expected ZACK to insure no data is lost. ZTSPARS cannot be used with ZCNL. 11.6 ZZZZSSSSKKKKIIIIPPPP Sent by the receiver in response to ZZZZFFFFIIIILLLLEEEE, makes the sender skip to the next file. 11.7 ZZZZNNNNAAAAKKKK Indicates last header was garbled. (See also ZZZZRRRRPPPPOOOOSSSS). 11.8 ZZZZAAAABBBBOOOORRRRTTTT Sent by receiver to terminate batch file transfers when requested by the user. Sender responds with a ZZZZFFFFIIIINNNN sequence.[2] 11.9 ZZZZFFFFIIIINNNN Sent by sending program to terminate a ZMODEM session. Receiver responds with its own ZZZZFFFFIIIINNNN. 11.10 ZZZZRRRRPPPPOOOOSSSS Sent by receiver to force file transfer to resume at file offset given in ZP0...ZP3. __________ 2. Or ZZZZCCCCOOOOMMMMPPPPLLLL in case of server mode. Chapter 11 Rev Oct-14-88 Typeset 10-14-88 28 Chapter 11 ZMODEM Protocol 29 11.11 ZZZZDDDDAAAATTTTAAAA ZP0...ZP3 contain file offset. One or more data subpackets follow. 11.12 ZZZZEEEEOOOOFFFF Sender reports End of File. ZP0...ZP3 contain the ending file offset. 11.13 ZZZZFFFFEEEERRRRRRRR Error in reading or writing file, protocol equivalent to ZZZZAAAABBBBOOOORRRRTTTT. 11.14 ZZZZCCCCRRRRCCCC Request (receiver) and response (sender) for file polynomial. ZP0...ZP3 contain file polynomial. 11.15 ZZZZCCCCHHHHAAAALLLLLLLLEEEENNNNGGGGEEEE Request sender to echo a random number in ZP0...ZP3 in a ZACK frame. Sent by the receiving program to the sending program to verify that it is connected to an operating program, and was not activated by spurious data or a Trojan Horse message. 11.16 ZZZZCCCCOOOOMMMMPPPPLLLL Request now completed. 11.17 ZZZZCCCCAAAANNNN This is a pseudo frame type returned by gethdr() in response to a Session Abort sequence. 11.18 ZZZZFFFFRRRREEEEEEEECCCCNNNNTTTT Sending program requests a ZACK frame with ZP0...ZP3 containing the number of free bytes on the current file system. A value of 0 represents an indefinite amount of free space. 11.19 ZZZZCCCCOOOOMMMMMMMMAAAANNNNDDDD ZCOMMAND is sent in a binary frame. ZZZZFFFF0000 contains 0000 or ZZZZCCCCAAAACCCCKKKK1111 (see below). A ZCRCW data subpacket follows, with the ASCII text command string terminated with a NULL character. If the command is intended to be executed by the operating system hosting the receiving program (e.g., "shell escape"), it must have "!" as the first character. Otherwise the command is meant to be executed by the application program which receives the command. Chapter 11 Rev Oct-14-88 Typeset 10-14-88 29 Chapter 11 ZMODEM Protocol 30 If the receiver detects an illegal or badly formed command, the receiver immediately responds with a ZCOMPL header with an error code in ZP0...ZP3. If ZF0 contained ZZZZCCCCAAAACCCCKKKK1111,,,, the receiver immediately responds with a ZCOMPL header with 0 status. Otherwise, the receiver responds with a ZCOMPL header when the operation is completed. The exit status of the completed command is stored in ZP0...ZP3. A 0 exit status implies nominal completion of the command. If the command causes a file to be transmitted, the command sender will see a ZRQINIT frame from the other computer attempting to send data. The sender examines ZF0 of the received ZRQINIT header to verify it is not an echo of its own ZRQINIT header. It is illegal for the sending program to command the receiving program to send a command. If the receiver program does not implement command downloading, it may display the command to the standard error output, then return a ZCOMPL header. 12. SSSSEEEESSSSSSSSIIIIOOOONNNN TTTTRRRRAAAANNNNSSSSAAAACCCCTTTTIIIIOOOONNNN EEEEXXXXAAAAMMMMPPPPLLLLEEEESSSS 12.1 AAAA ssssiiiimmmmpppplllleeee ffffiiiilllleeee ttttrrrraaaannnnssssffffeeeerrrr A simple transaction, one file, no errors, no CHALLENGE, overlapped I/O: Sender Receiver "rz\r" ZRQINIT(0) ZRINIT ZFILE ZRPOS ZDATA data ... ZEOF ZRINIT ZFIN ZFIN OO Chapter 12 Rev Oct-14-88 Typeset 10-14-88 30 Chapter 12 ZMODEM Protocol 31 12.2 CCCChhhhaaaalllllllleeeennnnggggeeee aaaannnndddd CCCCoooommmmmmmmaaaannnndddd DDDDoooowwwwnnnnllllooooaaaadddd Sender Receiver "rz\r" ZRQINIT(ZCOMMAND) ZCHALLENGE(random-number) ZACK(same-number) ZRINIT ZCOMMAND, ZDATA (Performs Command) ZCOMPL ZFIN ZFIN OO 13. ZZZZFFFFIIIILLLLEEEE FFFFRRRRAAAAMMMMEEEE FFFFIIIILLLLEEEE IIIINNNNFFFFOOOORRRRMMMMAAAATTTTIIIIOOOONNNN ZMODEM sends the same file information with the ZZZZFFFFIIIILLLLEEEE frame data that YMODEM Batch sends in its block 0. NNNN....BBBB....:::: TTTThhhheeee ppppaaaatttthhhhnnnnaaaammmmeeee ((((ffffiiiilllleeee nnnnaaaammmmeeee)))) ffffiiiieeeelllldddd iiiissss mmmmaaaannnnddddaaaattttoooorrrryyyy.... Pathname The pathname (conventionally, the file name) is sent as a null terminated ASCII string. This is the filename format used by the handle oriented MSDOS(TM) functions and C library fopen functions. An assembly language example follows: DB 'foo.bar',0 No spaces are included in the pathname. Normally only the file name stem (no directory prefix) is transmitted unless the sender has selected YAM's ffff option to send the ffffuuuullllllll absolute or relative pathname. The source drive designator (A:, B:, etc.) usually is not sent. FFFFiiiilllleeeennnnaaaammmmeeee CCCCoooonnnnssssiiiiddddeeeerrrraaaattttiiiioooonnnnssss o+ File names should be translated to lower case unless the sending system supports upper/lower case file names. This is a convenience for users of systems (such as Unix) which store filenames in upper and lower case. o+ The receiver should accommodate file names in lower and upper case. o+ When transmitting files between different operating systems, file names must be acceptable to both the sender and receiving operating systems. If not, transformations should be applied to make the file names acceptable. If the transformations are unsuccessful, a new file name may Chapter 13 Rev Oct-14-88 Typeset 10-14-88 31 Chapter 13 ZMODEM Protocol 32 be invented be the receiving program. If directories are included, they are delimited by /; i.e., "subdir/foo" is acceptable, "subdir\foo" is not. Length The file length and each of the succeeding fields are optional.[1] The length field is stored as a decimal string counting the number of data bytes in the file. The ZMODEM receiver uses the file length as an estimate only. It may be used to display an estimate of the transmission time, and may be compared with the amount of free disk space. The actual length of the received file is determined by the data transfer. A file may grow after transmission commences, and all the data will be sent. Modification Date A single space separates the modification date from the file length. The mod date is optional, and the filename and length may be sent without requiring the mod date to be sent. The mod date is sent as an octal number giving the time the ccccoooonnnntttteeeennnnttttssss of the file were last changed measured in seconds from Jan 1 1970 Universal Coordinated Time (GMT). A date of 0 implies the modification date is unknown and should be left as the date the file is received. This standard format was chosen to eliminate ambiguities arising from transfers between different time zones. File Mode A single space separates the file mode from the modification date. The file mode is stored as an octal string. Unless the file originated from a Unix system, the file mode is set to 0. rz(1) checks the file mode for the 0x8000 bit which indicates a Unix type regular file. Files with the 0x8000 bit set are assumed to have been sent from another Unix (or similar) system which uses the same file conventions. Such files are not translated in any way. Serial Number A single space separates the serial number from the file mode. The serial number of the transmitting program is stored as an octal string. Programs which do not have a serial __________ 1. Fields may not be skipped. Chapter 13 Rev Oct-14-88 Typeset 10-14-88 32 Chapter 13 ZMODEM Protocol 33 number should omit this field, or set it to 0. The receiver's use of this field is optional. Number of Files Remaining Iff the number of files remaining is sent, a single space separates this field from the previous field. This field is coded as a decimal number, and includes the current file. This field is an estimate, and incorrect values must not be allowed to cause loss of data. The receiver's use of this field is optional. Number of Bytes Remaining Iff the number of bytes remaining is sent, a single space separates this field from the previous field. This field is coded as a decimal number, and includes the current file. This field is an estimate, and incorrect values must not be allowed to cause loss of data. The receiver's use of this field is optional. File Type Iff the file type is sent, a single space separates this field from the previous field. This field is coded as a decimal number. Currently defined values are: 0 Sequential file - no special type 1 Other types to be defined. The receiver's use of this field is optional. The file information is terminated by a null. If only the pathname is sent, the pathname is terminated with ttttwwwwoooo nulls. The length of the file information subpacket, including the trailing null, must not exceed 1024 bytes; a typical length is less than 64 bytes. 14. PPPPEEEERRRRFFFFOOOORRRRMMMMAAAANNNNCCCCEEEE RRRREEEESSSSUUUULLLLTTTTSSSS 14.1 CCCCoooommmmppppaaaattttiiiibbbbiiiilllliiiittttyyyy Extensive testing has demonstrated ZMODEM to be compatible with satellite links, packet switched networks, microcomputers, minicomputers, regular and error correcting buffered modems at 75 to 19200 bps. ZMODEM's economy of reverse channel bandwidth allows modems that dynamically partition bandwidth between the two directions to operate at optimal speeds. Chapter 14 Rev Oct-14-88 Typeset 10-14-88 33 Chapter 14 ZMODEM Protocol 34 14.2 TTTThhhhrrrroooouuuugggghhhhppppuuuutttt Between two single task PC-XT computers sending a program image on an in house Telenet link, SuperKermit provided 72 ch/sec throughput at 1200 baud. YMODEM-k yielded 85 chars/sec, and ZMODEM provided 113 chars/sec. XMODEM was not measured, but would have been much slower based on observed network propagation delays. Recent tests downloading large binary files to an IBM PC (4.7 mHz V20) running YAMK 16.30 with table driven 32 bit CRC calculation yielded a throughput of 1870 cps on a 19200 bps direct connection. Tests with TELEBIT TrailBlazer modems have shown transfer rates approaching 1400 characters per second for long files. When files are compressed, effective transfer rates of 2000 characters per second are possible. 14.3 EEEErrrrrrrroooorrrr RRRReeeeccccoooovvvveeeerrrryyyy Some tests of ZMODEM protocol error recovery performance have been made. A PC-AT with SCO SYS V Xenix or DOS 3.1 was connected to a PC with DOS 2.1 either directly at 9600 bps or with unbuffered dial-up 1200 bps modems. The ZMODEM software was configured to use 1024 byte data subpacket lengths above 2400 bps, 256 otherwise. Because no time delays are necessary in normal file transfers, per file negotiations are much faster than with YMODEM, the only observed delay being the time required by the program(s) to update logging files. During a file transfer, a short line hit seen by the receiver usually induces a CRC error. The interrupt sequence is usually seen by the sender before the next data subpacket is completely sent, and the resultant loss of data throughput averages about half a data subpacket per line hit. At 1200 bps this is would be about .75 second lost per hit. At 10-5 error rate, this would degrade throughput by about 9 per cent. The throughput degradation increases with increasing channel delay, as more data subpackets in transit through the channel are discarded when an error is detected. A longer noise burst that affects both the receiver and the sender's reception of the interrupt sequence usually causes the sender to remain silent until the receiver times out in 10 seconds. If the round trip channel delay exceeds the receiver's 10 second timeout, recovery from this type of error may become difficult. Noise affecting only the sender is usually ignored, with one common exception. Spurious XOFF characters generated by noise stop the Chapter 14 Rev Oct-14-88 Typeset 10-14-88 34 Chapter 14 ZMODEM Protocol 35 sender until the receiver times out and sends an interrupt sequence which concludes with an XON. In summation, ZMODEM performance in the presence of errors resembles that of X.PC and SuperKermit. Short bursts cause minimal data retransmission. Long bursts (such as pulse dialing noises) often require a timeout error to restore the flow of data. 15. PPPPAAAACCCCKKKKEEEETTTT SSSSWWWWIIIITTTTCCCCHHHHEEEEDDDD NNNNEEEETTTTWWWWOOOORRRRKKKK CCCCOOOONNNNSSSSIIIIDDDDEEEERRRRAAAATTTTIIIIOOOONNNNSSSS Flow control is necessary for printing messages and directories, and for streaming file transfer protocols. A non transparent flow control is incompatible with XMODEM and YMODEM transfers. XMODEM and YMODEM protocols require complete transparency of all 256 8 bit codes to operate properly. The "best" flow control (when X.25 or hardware CTS is unavailable) would not "eat" any characters at all. When the PAD's buffer almost fills up, an XOFF should be emitted. When the buffer is no longer nearly full, send an XON. Otherwise, the network should neither generate nor eat XON or XOFF control characters. On Telenet, this can be met by setting CCIT X3 5:1 and 12:0 at bbbbooootttthhhh ends of the network. For best throughput, parameter 64 (advance ACK) should be set to something like 4. Packets should be forwarded when the packet is a full 128 bytes, or after a moderate delay (3:0,4:10,6:0). With PC-Pursuit, it is sufficient to set parameter 5 to 1 at both ends after one is connected to the remote modem. <ENTER>@<ENTER> set 5:1<ENTER> rst? 5:1<ENTER> cont<ENTER> Unfortunately, many PADs do not accept the "rst?" command. For YMODEM, PAD buffering should guarantee that a minimum of 1040 characters can be sent in a burst without loss of data or generation of flow control characters. Failure to provide this buffering will generate excessive retries with YMODEM. Chapter 15 Rev Oct-14-88 Typeset 10-14-88 35 Chapter 15 ZMODEM Protocol 36 TTTTAAAABBBBLLLLEEEE 1111.... Network and Flow Control Compatibility ______________________________________________________________________________ | Connectivity | Interactive| XMODEM| WXMODEM| SUPERKERMIT| ZMODEM | _|________________________________________|____________________________|__________________|____________________|____________________________|____________________|_ _|____________________|______________|_________|__________|______________|__________| |Direct Connect | YES | YES | YES | YES | YES | _|____________________|______________|_________|__________|______________|__________| |Network, no FC | nnnnoooo | YES | (4) | (6) | YES (1)| _|____________________|______________|_________|__________|______________|__________| |Net, transparent FC| YES | YES | YES | YES | YES | _|____________________|______________|_________|__________|______________|__________| |Net, non-trans. FC | YES | nnnnoooo | no (5) | YES | YES | _|____________________|______________|_________|__________|______________|__________| |Network, 7 bit | YES | nnnnoooo | no | YES (2) | YES (3)| _|____________________|______________|_________|__________|______________|__________| (1) ZMODEM can optimize window size or burst length for fastest transfers. (2) Parity bits must be encoded, slowing binary transfers. (3) Natural protocol extension possible for encoding data to 7 bits. (4) Small WXMODEM window size may may allow operation. (5) Some flow control codes are not escaped in WXMODEM. (6) Kermit window size must be reduced to avoid buffer overrun. 16. PPPPEEEERRRRFFFFOOOORRRRMMMMAAAANNNNCCCCEEEE CCCCOOOOMMMMPPPPAAAARRRRIIIISSSSOOOONNNN TTTTAAAABBBBLLLLEEEESSSS "Round Trip Delay Time" includes the time for the last byte in a packet to propagate through the operating systems and network to the receiver, plus the time for the receiver's response to that packet to propagate back to the sender. The figures shown below are calculated for round trip delay times of 40 milliseconds and 5 seconds. Shift registers in the two computers and a pair of 212 modems generate a round trip delay time on the order of 40 milliseconds. Operation with busy timesharing computers and networks can easily generate round trip delays of five seconds. Because the round trip delays cause visible interruptions of data transfer when using XMODEM protocol, the subjective effect of these delays is greatly exaggerated, especially when the user is paying for connect time. A 102400 byte binary file with randomly distributed codes is sent at 1200 bps 8 data bits, 1 stop bit. The calculations assume no transmission errors. For each of the protocols, only the per file functions are considered. Processor and I/O overhead are not included. YM-k refers to YMODEM with 1024 byte data packets. YM-g refers to the YMODEM "g" option. ZMODEM uses 256 byte data subpackets for this example. SuperKermit uses maximum standard Chapter 16 Rev Oct-14-88 Typeset 10-14-88 36 Chapter 16 ZMODEM Protocol 37 packet size, 8 bit transparent transmission, no run length compression. The 4 block WXMODEM window is too small to span the 5 second delay in this example; the resulting thoughput degradation is ignored. For comparison, a straight "dump" of the file contents with no file management or error checking takes 853 seconds. TTTTAAAABBBBLLLLEEEE 2222.... Protocol Overhead Information (102400 byte binary file, 5 Second Round Trip) ____________________________________________________________________________ | Protocol | XMODEM| YM-k | YM-g| ZMODEM| SKermit| WXMODEM| _|____________________________________________|__________________|________________|______________|__________________|____________________|____________________|_ _|______________________|_________|________|_______|_________|__________|__________| |Protocol Round Trips | 804 | 104 | 5 | 5 | 5 | 4 | _|______________________|_________|________|_______|_________|__________|__________| |Trip Time at 40ms | 32s | 4s | 0 | 0 | 0 | 0 | _|______________________|_________|________|_______|_________|__________|__________| |Trip Time at 5s | 4020s | 520s | 25s | 25s | 25 | 20 | _|____________________________________________|__________________|________________|______________|__________________|____________________|____________________|_ _|______________________|_________|________|_______|_________|__________|__________| |Overhead Characters | 4803 | 603 | 503 | 3600 | 38280 | 8000 | _|____________________________________________|__________________|________________|______________|__________________|____________________|____________________|_ _|______________________|_________|________|_______|_________|__________|__________| |Line Turnarounds | 1602 | 204 | 5 | 5 | 2560 | 1602 | _|____________________________________________|__________________|________________|______________|__________________|____________________|____________________|_ _|______________________|_________|________|_______|_________|__________|__________| |Transfer Time at 0s | 893s | 858s | 857s| 883s | 1172s | 916s | _|______________________|_________|________|_______|_________|__________|__________| |Transfer Time at 40ms| 925s | 862s | 857s| 883s | 1172s | 916s | _|______________________|_________|________|_______|_________|__________|__________| |Transfer Time at 5s | 5766s | 1378s| 882s| 918s | 1197s | 936s | _|______________________|_________|________|_______|_________|__________|__________| FFFFiiiigggguuuurrrreeee 5555.... Transmission Time Comparison (102400 byte binary file, 5 Second Round Trip) ************************************************** XMODEM ************ YMODEM-K ********** SuperKermit (Sliding Windows) ******* ZMODEM 16kb Segmented Streaming ******* ZMODEM Full Streaming ******* YMODEM-G Chapter 16 Rev Oct-14-88 Typeset 10-14-88 37 Chapter 16 ZMODEM Protocol 38 TTTTAAAABBBBLLLLEEEE 3333.... Local Timesharing Computer Download Performance __________________________________________________________________________ | Command | Protocol| Time/HD| Time/FD| Throughput| Efficiency| _|________________________________|______________________|____________________|____________________|__________________________|__________________________|_ _|________________|___________|__________|__________|_____________|_____________| |kermit -x | Kermit | 1:49 | 2:03 | 327 | 34% | _|________________|___________|__________|__________|_____________|_____________| |sz -Xa phones.t| XMODEM | 1:20 | 1:44 | 343 | 36% | _|________________|___________|__________|__________|_____________|_____________| |sz -a phones.t | ZMODEM | :39 | :48 | 915 | 95% | _|________________|___________|__________|__________|_____________|_____________| Times were measured downloading a 35721 character text file at 9600 bps, from Santa Cruz SysV 2.1.2 Xenix on a 9 mHz IBM PC-AT to DOS 2.1 on an IBM PC. Xenix was in multiuser mode but otherwise idle. Transfer times to PC hard disk and floppy disk destinations are shown. C-Kermit 4.2(030) used server mode and file compression, sending to Pro-YAM 15.52 using 0 delay and a "get phones.t" command. Crosstalk XVI 3.6 used XMODEM 8 bit checksum (CRC not available) and an "ESC rx phones.t" command. The Crosstalk time does nnnnooootttt include the time needed to enter the extra commands not needed by Kermit and ZMODEM. Professional-YAM used ZMODEM AutoDownload. ZMODEM times included a security challenge to the sending program. Chapter 16 Rev Oct-14-88 Typeset 10-14-88 38 Chapter 16 ZMODEM Protocol 39 TTTTAAAABBBBLLLLEEEE 4444.... File Transfer Speeds ______________________________________________________________________________ | Prot file bytes bps ch/sec Notes | _|__________________________________________________________________________________________________________________________________________________________|_ |X jancol.c 18237 2400 53 Tymnet PTL 5/3/87 | |X source.xxx 6143 2400 56 Source PTL 5/29/87 | |X jancol.c 18237 2400 64 Tymnet PTL | |XN tsrmaker.arc 25088 1200 94 GEnie PTL | |B/ovth emaibm.arc 51200 1200 101 CIS PTL MNP | |UUCP 74 files, each >7000 1200 102 (Average) | |ZM jancol.c 18237 1200 112 DataPac (604-687-7144)| |X/ovth emaibm.arc 51200 1200 114 CIS PTL MNP | |ZM emaibm.arc 51200 1200 114 CIS PTL MNP | |ZM frombyte87.txt 62506 1200 117 BIX | |SK source.xxx 6143 2400 170 Source PTL 5/29/87 | |ZM jancol.c 18237 2400 221 Tymnet PTL upl/dl | |B/ovth destro.gif 33613 2400 223 CIS/PTL 9-12-87 | |ZM jancol.c 18237 2400 224 Tymnet PTL | |ZM tp40kerm.arc 112640 2400 224 BIX 6/88 | |ZM readme.lis 9466 2400 231 BIX 6/88 | |ZM jancol.c 18237 2400 226/218 TeleGodzilla upl | |ZM jancol.c 18237 2400 226 Tymnet PTL 5/3/87 | |ZM zmodem.ov 35855 2400 227 CIS PTL node | |C jancol.c 18237 2400 229 Tymnet PTL 5/3/87 | |ZM jancol.c 18237 2400 229/221 TeleGodzilla | |ZM zmodem.ov 35855 2400 229 CIS PTL node upl | |ZM jancol.c 18237 2400 232 CIS PTL node | |QB gifeof.arc 32187 2400 232 CIS PTL node | |ZM pcpbbs.txt 38423 2400 534 MNP Level 5 | |ZM mbox 473104 9600 948/942 TeleGodzilla upl | |ZM zmodem.arc 318826 14k 1357/1345 TeleGodzilla | |ZM mbox 473104 14k 1367/1356 TeleGodzilla upl | |ZM c2.doc 218823 38k 3473 Xenix 386 TK upl | |ZM mbox -a 511893 38k 3860 386 Xenix 2.2 Beta | |ZM c.doc 218823 57k 5611 AT Clone & 386 | _|_____________________________________________________________________________| Times are for downloads unless noted. Where two speeds are noted, the faster speed is reported by the receiver because its transfer time calculation excludes the security check and transaction log file processing. The TeleGodzilla computer is a 4.77 mHz IBM PC with a 10 MB hard disk. The 386 computer uses an Intel motherboard at 18 mHz 1ws. The AT Clone (QIC) runs at 8 mHz 0ws. Abbreviations: B Compuserve B Protocol QB Compuserve Quick-B/B+ Protocol B/ovth CIS B with Omen Technology OverThruster(TM) C Capture DC2/DC4 (no protocol) K Kermit MNP Microcom MNP error correcting SX/1200 modem Chapter 16 Rev Oct-14-88 Typeset 10-14-88 39 Chapter 16 ZMODEM Protocol 40 PTL Portland Oregon network node SK Sliding Window Kermit (SuperKermit) w=15 X XMODEM XN XMODEM protocol implemented in network modes X/ovth XMODEM, Omen Technology OverThruster(TM) ZM ZMODEM Chapter 16 Rev Oct-14-88 Typeset 10-14-88 40 Chapter 16 ZMODEM Protocol 41 TTTTAAAABBBBLLLLEEEE 5555.... Protocol Checklist Etc: Relay, BLAST, DART _________________________________________________________________________ |Item XMODEM YMDM-k YMDM-g ZMODEM SK Etc.| _|________________________________________________|__________________|__________________|________________|________________|________________|____________|_ |IIIINNNN SSSSEEEERRRRVVVVIIIICCCCEEEE | 1977 | 1982 | 1985 | 1986 | 1985 | ? | |VENDORS | ?? | ?? | >20 | >20 | ?? | 1 | _|________________________________________________|__________________|__________________|________________|________________|________________|____________|_ |HOST AVAILABILITY | | | | | | | |Compuserve | YES | - | - | YES | - | - | |BIX | YES | - | - | YES | YES | - | |Portal | | | YES | - | - | SOON| |The Source | YES | - | - | - | YES | - | _|________________________|_________|_________|________|________|________|______| |UUUUSSSSEEEERRRR FFFFEEEEAAAATTTTUUUURRRREEEESSSS | | | | | | | |User Friendly | - | - | - | YES | (10) | - | |Commands/batch | 2*N | 2 | 2 | 1 | 1(1) | | |Commands/file | 2 | 0 | 0 | 0 | 0 | | |Command Download | - | - | - | YES | YES(6)| - | |Menu Compatible | - | - | - | YES | - | - | |Crash Recovery | - | - | - | YES | - | ?? | |File Management | - | - | - | YES | - | some| |Security Check | - | - | - | YES | - | - | _|________________________|_________|_________|________|________|________|______| |CCCCOOOOMMMMPPPPAAAATTTTIIIIBBBBIIIILLLLIIIITTTTYYYY | | | | | | | |Dynamic Files | YES | - | - | YES | YES | ? | |Packet SW NETS | - | - | - | YES | YES | ? | |7 bit PS NETS | - | - | - | (3) | YES | ? | |Old Mainframes | - | - | - | (3) | YES | ? | _|________________________|_________|_________|________|________|________|______| |AAAATTTTTTTTRRRRIIIIBBBBUUUUTTTTEEEESSSS | | | | | | | |Reliability(5) | fair | fair(5)| none | BEST | good | ? | |Streaming | - | - | YES | YES | YES | | |Overhead(2) | 7% | 1% | 1% | 4%(8) | 30% | | |Faithful Xfers | - | YES(7) | YES(7)| YES | YES | ? | |Preserve Date | - | YES | YES | YES | - | ? | _|________________________|_________|_________|________|________|________|______| |CCCCOOOOMMMMPPPPLLLLEEEEXXXXIIIITTTTYYYY | | | | | | | |No-Wait Sample | - | - | - | opt | REQD | REQD| |Ring Buffers | - | - | - | opt | REQD | REQD| |Complexity | LOW(5)| LOW(5) | LOW | MED | HIGH | ? | _|________________________|_________|_________|________|________|________|______| |EEEEXXXXTTTTEEEENNNNSSSSIIIIOOOONNNNSSSS | | | | | | | |Server Operation | - | - | - | YES(4)| YES | ? | |Multiple Threads | - | - | - | future| - | - | _|________________________________________________|__________________|__________________|________________|________________|________________|____________|_ NOTES: (1) Server mode or Omen Technology Kermit AutoDownload (2) Character count, binary file, transparent channel Chapter 16 Rev Oct-14-88 Typeset 10-14-88 41 Chapter 16 ZMODEM Protocol 42 (3) Future enhancement provided for (4) AutoDownload operation (5) Omen Technology's CCCCyyyybbbbeeeerrrrnnnneeeettttiiiicccc DDDDaaaattttaaaa RRRReeeeccccoooovvvveeeerrrryyyy((((TTTTMMMM)))) improves XMODEM and YMODEM reliability with complex proprietary logic. (6) Server commands only (7) Only with True YMODEM(TM) (8) More then 3% from protected network control characters (9) With Segmented Streaming (10) With Pro-YAM extensions Chapter 16 Rev Oct-14-88 Typeset 10-14-88 42 Chapter 16 ZMODEM Protocol 43 17. FFFFUUUUTTTTUUUURRRREEEE EEEEXXXXTTTTEEEENNNNSSSSIIIIOOOONNNNSSSS Future extensions include: o+ Compatibility with 7 bit networks o+ Server/Link Level operation: An END-TO-END error corrected program to program session is required for financial and other sensitive applications. o+ Multiple independent threads o+ Bidirectional transfers (STEREO ZMODEM) o+ Encryption o+ Compression o+ File Comparison o+ Selective transfer within a file (e.g., modified segments of a database file) o+ Selective Retransmission for error correction 18. RRRREEEEVVVVIIIISSSSIIIIOOOONNNNSSSS 10-14-88 Pascal source code now available in Phil Burn's PibTerm v4.2. 6-24-88 An exception to the previously unconditional ZCBIN override: a ZCRESUM specified by the receiver need not be overridden by the sender's ZCBIN. 11-18-87 Editorial improvements 10-27-87 Optional fields added for number of files remaining to be sent and total number of bytes remaining to be sent. 07-31-1987 The receiver should ignore a ZEOF with an offset that does not match the current file length. The previous action of responding with ZRPOS caused transfers to fail if a CRC error occurred immediately before end of file, because two retransmission requests were being sent for each error. This has been observed under exceptional conditions, such as data transmission at speeds greater than the receiving computer's interrupt response capabilitiy or gross misapplication of flow control. Discussion of the Tx backchannel garbage count and ZCRCW after error ZRPOS was added. Many revisions for clarity. 07-09-87 Corrected XMODEM's development date, incorrectly stated as Chapter 18 Rev Oct-14-88 Typeset 10-14-88 43 Chapter 18 ZMODEM Protocol 44 1979 instead of the actual August 1977. More performance data was added. 05-30-87 Added ZMNEW and ZMSKNOLOC 05-14-87 Window management, ZACK zshhdr XON removed, control character escaping, ZMSPARS changed to ZXPARS, editorial changes. 04-13-87 The ZMODEM file transfer protocol's public domain status is emphasized. 04-04-87: minor editorial changes, added conditionals for overview version. 03-15-87: 32 bit CRC added. 12-19-86: 0 Length ZCRCW data subpacket sent in response to ZPAD or ZDELE detected on reverse channel has been changed to ZCRCE. The reverse channel is now checked for activity before sending each ZDATA header. 11-08-86: Minor changes for clarity. 10-2-86: ZCNL definition expanded. 9-11-86: ZMPROT file management option added. 8-20-86: More performance data included. 8-4-86: ASCII DLE (Ctrl-P, 020) now escaped; compatible with previous versions. More document revisions for clarity. 7-15-86: This document was extensively edited to improve clarity and correct small errors. The definition of the ZMNEW management option was modified, and the ZMDIFF management option was added. The cancel sequence was changed from two to five CAN characters after spurious two character cancel sequences were detected. 19. MMMMOOOORRRREEEE IIIINNNNFFFFOOOORRRRMMMMAAAATTTTIIIIOOOONNNN Please contact Omen Technology for troff source files and typeset copies of this document. 19.1 TTTTeeeelllleeeeGGGGooooddddzzzziiiillllllllaaaa BBBBuuuulllllllleeeettttiiiinnnn BBBBooooaaaarrrrdddd More information may be obtained by calling the TeleGodzilla bulletin board at 503-621-3746. TeleGodzilla supports 19200 (Telebit PEP), 2400 and 1200 bps callers with automatic speed recognition. Chapter 19 Rev Oct-14-88 Typeset 10-14-88 44 Chapter 19 ZMODEM Protocol 45 Relevant files include YZMODEM.ZOO, YAMDEMO.ZOO, YAMHELP.ZOO, ZCOMMEXE.ARC, ZCOMMDOC.ARC, ZCOMMHLP.ARC. Useful commands for TeleGodzilla include "menu", "dir", "sx file (XMODEM)", "kermit sb file ...", and "sz file ...". 19.2 UUUUnnnniiiixxxx UUUUUUUUCCCCPPPP AAAAcccccccceeeessssssss UUCP sites can obtain the current version of this file with uucp omen!/u/caf/public/zmodem.doc /tmp A continually updated list of available files is stored in /usr/spool/uucppublic/FILES. uucp omen!~uucp/FILES /usr/spool/uucppublic The following L.sys line allows UUCP to call site "omen" via Omen's bulletin board system "TeleGodzilla". TeleGodzilla is an instance of Omen Technology's Professional-YAM in host operation, acting as a bulletin board and front ending a Xenix system. In response to TeleGodzilla's "Name Please:" (e:--e:), uucico gives the Pro-YAM "link" command as a user name. Telegodzilla then asks for a link password (d:). The password (Giznoid) controls access to the Xenix system connected to the IBM PC's other serial port. Communications between Pro-YAM and Xenix use 9600 bps; YAM converts this to the caller's speed. Finally, the calling uucico sees the Xenix "Login:" message (n:-- n:), and logs in as "uucp". No password is used for the uucp account. omen Any ACU 2400 1-503-621-3746 e:--e: link d: Giznoid n:--n: uucp 20. ZZZZMMMMOOOODDDDEEEEMMMM PPPPRRRROOOOGGGGRRRRAAAAMMMMSSSS A copy of this document, a demonstration version of Professional-YAM, a flash-up tree structured help file and processor, are available in _Y_Z_M_O_D_E_M._Z_O_O on TeleGodzilla and other bulletin boards. This file must be unpacked with _L_O_O_Z._E_X_E, also available on TeleGodzilla. _Y_Z_M_O_D_E_M._Z_O_O may be distributed provided none of the files are deleted or modified without the written consent of Omen Technology. TeleGodzilla and other bulletin boards also feature ZZZZCCCCOOOOMMMMMMMM, a shareware communications program. ZCOMM includes Omen Technology's TurboLearn(TM) Script Writer, ZMODEM, Omen's highly acclaimed XMODEM and YMODEM protocol support, Sliding Windows Kermit, several traditional protocols, a powerful script language, and the most accurate VT100/102 emulation available in a usr supported program. The ZCOMM files include: Chapter 20 Rev Oct-14-88 Typeset 10-14-88 45 Chapter 20 ZMODEM Protocol 46 o+ ZZZZCCCCOOOOMMMMMMMMEEEEXXXXEEEE....AAAARRRRCCCC Executable files and beginner's telephone directory o+ ZZZZCCCCOOOOMMMMMMMMDDDDOOOOCCCC....AAAARRRRCCCC "Universal Line Printer Edition" Manual o+ ZZZZCCCCOOOOMMMMMMMMHHHHLLLLPPPP....AAAARRRRCCCC Tree structured Flash-UP help processor and database C source code and manual pages for the Unix/Xenix _r_z and _s_z programs are available on TeleGodzilla in _R_Z_S_Z._Z_O_O. This ZOO archive may be unpacked with _L_O_O_Z._E_X_E, also available on TeleGodzilla. Most Unix like systems are supported, including V7, Sys III, 4.x BSD, SYS V, Idris, Coherent, and Regulus. _R_Z_S_Z._Z_O_O includes a ZCOMM/Pro-YAM/PowerCom script _Z_U_P_L._T to upload the small (178 lines) YMODEM bootstrap program _M_I_N_I_R_B._C without a file transfer protocol. _M_I_N_I_R_B uses the Unix stty(1) program to set the required raw tty modes, and compiles without special flags on virtually all Unix and Xenix systems. _Z_U_P_L._T directs the Unix system to compile _M_I_N_I_R_B, then uses it as a bootstrap to upload the rz/sz source and manual files. Pascal source code for ZMODEM support is available in PibTerm v4.2 written by Phil Burns. The PC-DOS EEEEXXXXEEEECCCC----PPPPCCCC,,,, QQQQuuuuiiiicccckkkkBBBBBBBBSSSS,,,, OOOOppppuuuussss and NNNNoooocccchhhhaaaannnnggggeeee bulletin boards support ZMODEM. Integrated ZMODEM support for the CCCCoooolllllllliiiieeee bulletin board program is planned. Most of the PC-DOS bulletin board programs that lack integrated ZMODEM support ZMODEM with external modules (DSZ, etc.). The BBBBiiiinnnnkkkklllleeeeyyyyTTTTeeeerrrrmmmm,,,, DDDDuuuuttttcccchhhhiiiieeee and DDDD''''BBBBrrrriiiiddddggggeeee email systems support ZMODEM as their primary protocol. The IIIINNNN----SSSSYYYYNNNNCCCCHHHH PC-DOS Teleconferencing system uses ZMODEM. The LAN modem sharing program LLLLiiiinnnneeee PPPPlllluuuussss has announced ZMODEM support. Many programs have added direct ZMODEM support, including Crosstalk Mark IV, and Telix 3. Most other PC-DOS communications programs support external ZMODEM via Omen Technology's DSZ, including PibTerm, Qmodem SST and BOYAN. The ZZZZMMMMDDDDMMMM communications program by Jwahar Bammi runs on Atari ST machines. The OOOOnnnnlllliiiinnnneeee!!!! and AAAA----TTTTaaaallllkkkk GGGGoooolllldddd programs for the Amiga support ZMODEM. The Byte Information eXchange supports ZMODEM. The Compuserve Information Service has ported the Unix rz/sz ZMODEM programs to Chapter 20 Rev Oct-14-88 Typeset 10-14-88 46 Chapter 20 ZMODEM Protocol 47 DECSYSTEM 20 assembler, and has announced future support for ZMODEM. 20.1 AAAAddddddddiiiinnnngggg ZZZZMMMMOOOODDDDEEEEMMMM ttttoooo DDDDOOOOSSSS PPPPrrrrooooggggrrrraaaammmmssss _D_S_Z is a small shareware program that supports XMODEM, YMODEM, and ZMODEM file transfers. _D_S_Z is designed to be called from a bulletin board program or another communications program. It may be called as dsz port 2 sz file1 file2 to send files, or as dsz port 2 rz to receive zero or more file(s), or as dsz port 2 rz filea fileb to receive two files, the first to _f_i_l_e_a and the second (if sent) to _f_i_l_e_b. This form of _d_s_z may be used to control the pathname of incoming file(s). In this example, if the sending program attempted to send a third file, the transfer would be terminated. _D_s_z uses DOS stdout for messages (no direct CRT access), acquires the COMM port vectors with standard DOS calls, and restores the COMM port's interrupt vector and registers upon exit. Further information on _d_s_z may be found in _d_s_z._d_o_c and the ZCOMM or Pro-YAM user manuals. 21. YYYYMMMMOOOODDDDEEEEMMMM PPPPRRRROOOOGGGGRRRRAAAAMMMMSSSS The Unix _r_z/_s_z programs support YMODEM as well as ZMODEM. Most Unix like systems are supported, including V7, Sys III, 4.2 BSD, SYS V, Idris, Coherent, and Regulus. A version for VAX-VMS is available in VRBSB.SHQ, in the same directory. Irv Hoff has added 1k packets and YMODEM transfers to the KMD and IMP series programs, which replace the XMODEM and MODEM7/MDM7xx series respectively. Overlays are available for a wide variety of CP/M systems. Many other programs, including MEX-PLUS and Crosstalk Mark IV also support some of YMODEM's features. Chapter 21 Rev Oct-14-88 Typeset 10-14-88 47 Chapter 21 ZMODEM Protocol 48 Questions about YMODEM, the Professional-YAM communications program, and requests for evaluation copies may be directed to: Chuck Forsberg Omen Technology Inc 17505-V Sauvie Island Road Portland Oregon 97231 VOICE: 503-621-3406 :VOICE Modem (TeleGodzilla): 503-621-3746 Usenet: ...!tektronix!reed!omen!caf Compuserve: 70007,2304 Source: TCE022 22. AAAACCCCKKKKNNNNOOOOWWWWLLLLEEEEDDDDGGGGMMMMEEEENNNNTTTTSSSS The High Reliability Software(TM), TurboLearn Script Writer(TM), Cybernetic Data Recovery(TM), AutoDownload(TM), Intelligent Crash Recovery(TM), Error Containment(TM), Full Time Capture(TM), True YMODEM(TM), OverThruster(TM), Password Guardian(TM), CryptoScript(TM), and TurboDial(TM) are Omen Technology trademarks. ZMODEM was developed _f_o_r _t_h_e _p_u_b_l_i_c _d_o_m_a_i_n under a Telenet contract. The ZMODEM protocol descriptions and the Unix rz/sz program source code are public domain. No licensing, trademark, or copyright restrictions apply to the use of the protocol, the Unix rz/sz source code and the _Z_M_O_D_E_M name. Encouragement and suggestions by Thomas Buck, Ward Christensen, Earl Hall, Irv Hoff, Stuart Mathison, and John Wales, are gratefully acknowledged. 32 bit CRC code courtesy Gary S. Brown. 23. RRRREEEELLLLAAAATTTTEEEEDDDD FFFFIIIILLLLEEEESSSS The following files may be useful while studying this document: YYYYMMMMOOOODDDDEEEEMMMM....DDDDOOOOCCCC Describes the XMODEM, XMODEM-1k, and YMODEM batch file transfer protocols. This file is available on TeleGodzilla as YMODEM.DQC. zzzzmmmmooooddddeeeemmmm....hhhh Definitions for ZMODEM manifest constants rrrrzzzz....cccc,,,, sssszzzz....cccc,,,, rrrrbbbbssssbbbb....cccc Unix source code for operating ZMODEM programs. rrrrzzzz....1111,,,, sssszzzz....1111 Manual pages for rz and sz (Troff sources). zzzzmmmm....cccc Operating system independent low level ZMODEM subroutines. mmmmiiiinnnniiiirrrrbbbb....cccc A YMODEM bootstrap program, 178 lines. Chapter 23 Rev Oct-14-88 Typeset 10-14-88 48 Chapter 23 ZMODEM Protocol 49 RRRRZZZZSSSSZZZZ....ZZZZOOOOOOOO,,,,rrrrzzzzsssszzzz....aaaarrrrcccc Contain the C source code and manual pages listed above, plus a ZCOMM script to upload minirb.c to a Unix or Xenix system, compile it, and use the program to upload the ZMODEM source files with error checking. DDDDSSSSZZZZ....ZZZZOOOOOOOO,,,,ddddsssszzzz....aaaarrrrcccc Contains DSZ.COM, a shareware X/Y/ZMODEM subprogram, DESQview "pif" files for background operation in minimum memory, and DSZ.DOC. ZZZZCCCCOOOOMMMMMMMM****....AAAARRRRCCCC Archive files for ZCOMM, a powerful shareware communications program. Chapter 23 Rev Oct-14-88 Typeset 10-14-88 49 CONTENTS 1. INTENDED AUDIENCE................................................ 2 2. WHY DEVELOP ZMODEM?.............................................. 2 3. ZMODEM Protocol Design Criteria.................................. 4 3.1 Ease of Use............................................... 4 3.2 Throughput................................................ 5 3.3 Integrity and Robustness.................................. 6 3.4 Ease of Implementation.................................... 6 4. EVOLUTION OF ZMODEM.............................................. 7 5. ROSETTA STONE.................................................... 10 6. ZMODEM REQUIREMENTS.............................................. 10 6.1 File Contents............................................. 10 7. ZMODEM BASICS.................................................... 12 7.1 Packetization............................................. 12 7.2 Link Escape Encoding...................................... 12 7.3 Header.................................................... 13 7.4 Binary Data Subpackets.................................... 16 7.5 ASCII Encoded Data Subpacket.............................. 16 8. PROTOCOL TRANSACTION OVERVIEW.................................... 16 8.1 Session Startup........................................... 16 8.2 File Transmission......................................... 18 8.3 Session Cleanup........................................... 20 8.4 Session Abort Sequence.................................... 20 9. STREAMING TECHNIQUES / ERROR RECOVERY............................ 21 9.1 Full Streaming with Sampling.............................. 21 9.2 Full Streaming with Reverse Interrupt..................... 23 9.3 Full Streaming with Sliding Window........................ 23 9.4 Full Streaming over Error Free Channels................... 24 9.5 Segmented Streaming....................................... 24 10. ATTENTION SEQUENCE............................................... 24 11. FRAME TYPES...................................................... 25 11.1 ZRQINIT................................................... 25 11.2 ZRINIT.................................................... 25 11.3 ZSINIT.................................................... 25 11.4 ZACK...................................................... 26 11.5 ZFILE..................................................... 26 11.6 ZSKIP..................................................... 28 11.7 ZNAK...................................................... 28 11.8 ZABORT.................................................... 28 - i - 11.9 ZFIN...................................................... 28 11.10 ZRPOS..................................................... 28 11.11 ZDATA..................................................... 29 11.12 ZEOF...................................................... 29 11.13 ZFERR..................................................... 29 11.14 ZCRC...................................................... 29 11.15 ZCHALLENGE................................................ 29 11.16 ZCOMPL.................................................... 29 11.17 ZCAN...................................................... 29 11.18 ZFREECNT.................................................. 29 11.19 ZCOMMAND.................................................. 29 12. SESSION TRANSACTION EXAMPLES..................................... 30 12.1 A simple file transfer.................................... 30 12.2 Challenge and Command Download............................ 31 13. ZFILE FRAME FILE INFORMATION..................................... 31 14. PERFORMANCE RESULTS.............................................. 33 14.1 Compatibility............................................. 33 14.2 Throughput................................................ 34 14.3 Error Recovery............................................ 34 15. PACKET SWITCHED NETWORK CONSIDERATIONS........................... 35 16. PERFORMANCE COMPARISON TABLES.................................... 36 17. FUTURE EXTENSIONS................................................ 43 18. REVISIONS........................................................ 43 19. MORE INFORMATION................................................. 44 19.1 TeleGodzilla Bulletin Board............................... 44 19.2 Unix UUCP Access.......................................... 45 20. ZMODEM PROGRAMS.................................................. 45 20.1 Adding ZMODEM to DOS Programs............................. 47 21. YMODEM PROGRAMS.................................................. 47 22. ACKNOWLEDGMENTS.................................................. 48 23. RELATED FILES.................................................... 48 LIST OF FIGURES Figure 1. Order of Bytes in Header................................... 14 Figure 2. 16 Bit CRC Binary Header................................... 14 - ii - Figure 3. 32 Bit CRC Binary Header................................... 14 Figure 4. HEX Header................................................. 15 Figure 5. Transmission Time Comparison............................... 37 LIST OF TABLES TABLE 1. Network and Flow Control Compatibility...................... 36 TABLE 2. Protocol Overhead Information............................... 37 TABLE 3. Local Timesharing Computer Download Performance............. 38 TABLE 4. File Transfer Speeds........................................ 39 TABLE 5. Protocol Checklist.......................................... 41 - iii - The ZMODEM Inter Application File Transfer Protocol Chuck Forsberg Omen Technology Inc _A_B_S_T_R_A_C_T The ZMODEM file transfer protocol provides reliable file and command transfers with complete EEEENNNNDDDD----TTTTOOOO----EEEENNNNDDDD data integrity between application programs. ZMODEM's 32 bit CRC protects against errors that continue to sneak into even the most advanced networks. Unlike traditional and many recently introduced protocols, ZMODEM safeguards all data and supervisory information with effective error detection. ZMODEM rapidly transfers files, particularly with buffered (error correcting) modems, timesharing systems, satellite relays, and wide area packet switched networks. User Friendliness is an important ZMODEM feature. ZMODEM AutoDownload (Automatic file Download initiated without user intervention) greatly simplifies file transfers compared to the traditional protocols. ZMODEM provides advanced file management features including Crash Recovery, flexible control of selective file transfers, and security verified command downloading. ZMODEM protocol features allow implementation on a wide variety of systems operating in a wide variety of environments. A choice of buffering and windowing modes allows ZMODEM to operate on systems that cannot support other streaming protocols. Finely tuned control character escaping allows operation with real world networks without Kermit's high overhead. ZMODEM is the only high performance high reliability public protocol that does not require large buffer allocations for normal file transfers. Although ZMODEM software is more complex than unreliable XMODEM routines, a comphrensive protocol description and actual C source code to pppprrrroooodddduuuuccccttttiiiioooonnnn programs have allowed dozens of developers to upgrade their applications with efficient, reliable ZMODEM file transfers with a minimum of effort. ZMODEM was developed _f_o_r _t_h_e _p_u_b_l_i_c _d_o_m_a_i_n under a Telenet contract. The ZMODEM protocol descriptions and the Unix rz/sz program source code are public domain. No licensing, trademark, or copyright restrictions apply to the use of the protocol, the Unix rz/sz source code and the _Z_M_O_D_E_M name.
jjung@nunki.usc.edu (John Jung) (10/16/88)
I don't want to sound ungrateful or anything, but that file doesn't help me a whole lot. I don't suppose you have a high-level, detailed description of how ZMODEM works, without the UNIX or C references? If not, let's call the whole thing off... John P.S. I'm sorry, but it does me no good to hear about when to ssend a ZACK() packet if I don't know what the ZACK() packet is...
julian@uhccux.uhcc.hawaii.edu (Julian Cowley) (10/19/88)
In article <1652@nunki.usc.edu> jjung@nunki.usc.edu (John Jung) writes: > I don't want to sound ungrateful or anything, but that file doesn't help >me a whole lot. > > I don't suppose you have a high-level, detailed description of how ZMODEM >works, without the UNIX or C references? If not, let's call the whole thing >off... Ok, so maybe Chuck won't win any awards for his writing style, but the fact is that Zmodem is a well-designed protocol and should be based on that. But still it wouldn't hurt to have a well-written document that includes explanations of buzzwords like sliding windows, packet-switched networks, and such. At the very least, maybe we could all pitch in and buy Chuck a spelling checker. As to your comment about the references to Unix, I don't see why they bother you. The Zmodem protocol is not adherent to it, and the document itself mentions considerations about other operating systems like MS-DOS, Macintoshes, and CP/M. >P.S. I'm sorry, but it does me no good to hear about when to ssend a ZACK() >packet if I don't know what the ZACK() packet is... If Zmodem is your first attempt at programming a protocol, I would suggest that you go back and start from scratch with vanilla Xmodem and work your way up through the family's hierarchy. Plain Xmodem is really simple to understand. By the time you get up to Ymodem-batch, you will have enough experience behind you that Zmodem is not much more of a hurdle. And the fact is that if you have a properly designed program, then it must have Ymodem built-in since Zmodem has to be able to fall back on it in case the sender or receiver does not support it. julian@uhccux.uhcc.hawaii.edu uunet!ucsd!nosc!uhccux!julian julian@uhccux.bitnet "People who aren't amused don't talk."