
     The ZMODEM Asynchronous Inter Application File Transfer Protocol

         Chuck Forsberg

      Omen Technology Inc


         Chuck Forsberg
      Omen Technology Inc
     17505-V Northwest Sauvie Island Road
     Portland Oregon 97231
      Voice: 503-621-3406
     Modem (TeleGodzilla): 503-621-3746 Speed 1200,300
     Compuserve: 70007,2304
      UUCP: ...!tektronix!reed!omen!caf




         CONTENTS


 1.  INTENDED AUDIENCE................................................  2

 2.  EVOLUTION OF ZMODEM..............................................  2

 3.  ACKNOWLEDGMENTS..................................................  4

 4.  RELATED DOCUMENTS................................................  4

 5.  ROSETTA STONE....................................................  5

 6.  WHY DEVELOP ZMODEM?..............................................  5

 7.  ZMODEM Protocol Design Criteria..................................  7
     7.1    Ease of Use...............................................  7
     7.2    Throughput................................................  8
     7.3    Integrity and Robustness..................................  8
     7.4    Ease of Implementation....................................  8

 8.  ZMODEM REQUIREMENTS..............................................  9
     8.1    File Contents.............................................  9

 9.  ZMODEM BASICS.................................................... 10
     9.1    Packetization............................................. 10
     9.2    Link Escape Encoding...................................... 11
     9.3    Header.................................................... 12
     9.4    Binary Data Subpackets.................................... 14
     9.5    ASCII Encoded Data Subpacket.............................. 14

10.  PROTOCOL TRANSACTION OVERVIEW.................................... 14
     10.1   Session Startup........................................... 14
     10.2   File Transmission......................................... 15
     10.3   Session Cleanup........................................... 17
     10.4   Session Cancel Sequence................................... 18

11.  STREAMING TECHNIQUES / ERROR RECOVERY............................ 19
     11.1   Full Streaming with Sampling.............................. 19
     11.2   Full Streaming with Reverse Interrupt..................... 20
     11.3   Full Streaming with a Sliding Window...................... 20
     11.4   Full Streaming over Error Free Channels................... 21
     11.5   Segmented Streaming....................................... 21

12.  ATTENTION SEQUENCE............................................... 21

13.  FRAME TYPES...................................................... 22
     13.1   ZRQINIT................................................... 22
     13.2   ZRINIT.................................................... 22
     13.3   ZSINIT.................................................... 22
     13.4   ZACK...................................................... 22


      - i -

     13.5   ZFILE..................................................... 23
     13.6   ZSKIP..................................................... 24
     13.7   ZNAK...................................................... 24
     13.8   ZABORT.................................................... 25
     13.9   ZFIN...................................................... 25
     13.10  ZRPOS..................................................... 25
     13.11  ZDATA..................................................... 25
     13.12  ZEOF...................................................... 25
     13.13  ZFERR..................................................... 25
     13.14  ZCRC...................................................... 25
     13.15  ZCHALLENGE................................................ 25
     13.16  ZCOMPL.................................................... 26
     13.17  ZCAN...................................................... 26
     13.18  ZFREECNT.................................................. 26
     13.19  ZCOMMAND.................................................. 26

14.  SESSION TRANSACTION EXAMPLES..................................... 27
     14.1   A simple file transfer.................................... 27
     14.2   Challenge and Command Download............................ 27

15.  ZFILE FRAME FILE INFORMATION..................................... 27

16.  PERFORMANCE RESULTS.............................................. 30
     16.1   Compatibility............................................. 30
     16.2   Throughput................................................ 30
     16.3   Error Recovery............................................ 30

17.  PACKET SWITCHED NETWORK CONSIDERATIONS........................... 31

18.  PERFORMANCE COMPARISON TABLES.................................... 32

19.  FUTURE EXTENSIONS................................................ 36

20.  REVISIONS........................................................ 36

21.  MORE INFORMATION................................................. 37

22.  ZMODEM PROGRAMS.................................................. 37
     22.1   Adding ZMODEM to DOS Programs............................. 38

23.  YMODEM PROGRAMS.................................................. 39

      - ii -


        LIST OF FIGURES


Figure 1.  Order of Bytes in Header................................... 12

Figure 2.  Binary Header.............................................. 13

Figure 3.  HEX Header................................................. 13

Figure 4.  Transmission Time Comparison............................... 33

     - iii -


         LIST OF TABLES


TABLE 1.  Network and Flow Control Compatibility...................... 32

TABLE 2.  Protocol Overhead Information............................... 33

TABLE 3.  Local Timesharing Computer Download Performance............. 33

TABLE 4.  Protocol Checklist.......................................... 35


      - iv -




     The ZMODEM Asynchronous Inter Application File Transfer Protocol

         Chuck Forsberg

      Omen Technology Inc


     ABSTRACT



The ZMODEM file transfer protocol provides efficient file transfers with
high speed buffered modems, timesharing systems, satellite relays, and
wide area packet switched networks.

ZMODEM greatly simplifies file transfers compared to XMODEM.  In addition
to allowing a friendly user interface, ZMODEM provides Personal Computer
and other users an efficient, accurate, and robust file transfer method.

ZMODEM provides advanced file management features including AutoDownload
(Automatic file Download initiated without user intervention), aborted
transfer recovery, 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.

Although ZMODEM software is more complex than primitive XMODEM routines,
actual C source code to production programs allows developers to upgrade
their applications with efficient, reliable ZMODEM file transfers with a
minimum of effort.

ZMODEM is carefully designed to provide these benefits using a minimum of
new software technology beyond XMODEM/CRC.  ZMODEM can be implemented on
all but the most throughly brain damaged microcomputers.



1.  INTENDED AUDIENCE

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.  EVOLUTION OF ZMODEM

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?  
Pure binary ( used by WXMODEM protocol) was out because some binary code combinations won't pass bidirectionally
through networks and operating systems.  Other operating systems may not
be able to recognize something coming back unless a break signal or a
system dependent code or sequence is present.(Without stopping for a response) By the time all this and
other fundamental problems were corrected, XMODEM's simple ACK and NACK
characters had evolved into a real packet.

Managing the window  (The WINDOW is the data in transit between sender and receiver) was another problem.  Experience gained in
debugging The Source's SuperKermit protocol indicated a window size of
about 1000 characters was needed at 1200 bps.  This extrapolates to the
better part of 20000 characters at 19.2 kbps.  Much of the SuperKermit's
complexity and debugging time centered around its ring buffering and
window management.  There had to be an easier way to get the job done.

A sore point in XMODEM and YMODEM 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 pass 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 that does not appear
anywhere else. WXMODEM and ZMODEM use character sequences to delineate
the start of frames.

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

For ZMODEM, we decided to forgo the complexity of SuperKermit's selective
retransmission 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 accpetable with old CP/M files which had no exact length, but not
with modern systems such as 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.
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 analagous to BISYNC and
HDLC.

The end result was a ZMOEM header containing a "frame type", four bytes of
supervisory information, and its own CRC-16.  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 simply 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 (network friendly) frames, the
sending program can send an "invitation to receive" sequence to activate
the receiver without undue concern of crashing the remote application with
unexpected  control characters.

Going "back to scratch" in the protocol design presents an oppurtunity 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.



3.  ACKNOWLEDGMENTS

Encouragement and suggestions by Thomas Buck, Ward Christensen, Earl Hall,
Irv Hoff, Stuart Mathison, and John Wales, are gratefully acknowledged.


4.  RELATED DOCUMENTS

The following files may be useful while studying this document:

YMODEM.DOC Describes the XMODEM and YMODEM file transfer protocols

zmodem.h Provides definitions for the manifest constants referenced
 herein.

rz.c, sz.c, rbsb.c Unix source code for operating ZMODEM programs.

rz.1, sz.1 Manual pages for rz and sz (Troff sources).

zm.c Operating system independent low level ZMODEM subroutines.


5.  ROSETTA STONE

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 1979 file transfer etiquette introduced by
 Ward Christensen's 1979 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.

YMODEM refers to the XMODEM/CRC protocol with the throughput and/or batch
 transmission enhancements described in YMODEM.DOC.


6.  WHY DEVELOP ZMODEM?

Since its development half a decade ago, the Ward Christensen MODEM
protocol has enabled a wide variety of computer systems to interchange
data.  There is hardly a communications program that doesn't at least
claim to support this protocol, now called XMODEM.

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:

   + The user interface is suitable for computer hobbyists.  Multiple
     commands must be keyboarded to transfer each file.

   + Since commands must be given to both programs, simple menu selections
     are not possible.

   + The short block length causes throughput to suffer when used with
     timesharing systems, packet switched networks, satellite circuits,
     and buffered (error correcting) modems.

   + The 8 bit checksum and unprotected transactions allow undetected
     errors and disrupted file transfers.

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

   + The transmitted file accumulates as many as 127 bytes of garbage.

   + The modification date and other file attributes are lost.

   + XMODEM requires complete 8 bit transparency, all 256 codes.  XMODEM
     will not operate over some networks that use ASCII flow control or
     escape codes.  Setting pure transparency often disables important
     network control functions for the duration of the call.

A number of other protocols have been developed over the years, but none
have displaced XMODEM to date.

   + Lack of public domain documentation and example programs have kept
     proprietary protocols such as MNP, Blast, and others tightly bound to
     the fortunes of their suppliers.

   + Link level protocols such as X.25, X.PC, and MNP do not manage
     application to application file transfers.

   + The Kermit 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.(Some Kermit programs support run length encoding)

     Kermit Sliding Windows ("SuperKermit") improves throughput over
     networks at the cost of increased complexity.  SuperKermit state
     transitions are encoded in a special language "wart" which requires a
     C compiler.  The SuperKermit C code 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.

     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.


A number of extensions to the XMODEM protocol have been made.

 + XMODEM-k uses 1024 byte blocks to reduce the overhead from transmission
   delays by 87 per cent compared to XMODEM, but network delays can still
   degrade performance.  Some networks may not be able to transmit 1024
   byte packets.

 + The handling of files that are not a multiple of 1024 or 128 bytes is
   awkward, especially if the file length is not known, or changes during
   transmission.

 + YMODEM-g provides efficient batch file transfers, preserving exact file
   length and file modification date.  YMODEM-g is essentially insensitive
   to network delays.  Because it does not support error recovery,
   YMODEM-g is usually used hardwired or with a reliable link level
   protocol.  IF YMODEM-g detects a CRC error, data transfers are aborted.
   YMODEM-g is easy to implement because it closely resembles XMODEM-CRC.

Another XMODEM "extension" is protocol cheating, referred to as "Turbo
Download" and OverThruster. These sometimes improve XMODEM throughput
by disabling error recovery.

The ZMODEM Protocol corrects the weaknesses described above while
maintaining as much of XMODEM/CRC's simplicity and prior art as possible.



7.  ZMODEM Protocol Design Criteria

The design of a file transfer protocol is an engineering compromise
between conflicting requirements:

7.1  Ease of Use

 + ZMODEM allows either program to initiate file transfers, passing
   commands and/or modifiers to the other program.

 + File names need be entered only once.

 + Menu selections are supported.

 + Wild Card names may be used with batch transfers.

 + Minimum keystrokes required to initiate transfers.

 + ZRQINIT frame sent by sending program can trigger automatic downloads.

 + ZMODEM can step down to X/YMODEM if the other end does not support
   ZMODEM. (Provided the transmission medium accommodates X/YMODEM)

7.2  Throughput

ZMODEM is designed for optimum performance with almost no degradation
caused by delays introduced by packet switched networks and timesharing
systems.

ZMODEM is optimized for best throughput over networks where line hits
occur infrequently.  This assumption markedly reduces code complexity and
memory requirements.  ZMODEM protocol features enhance rapid error
recovery compared to network compatible XMODEM implementations.

In the absence of network delays, error recovery is rapid, much faster
than YMODEM or network compatible versions of XMODEM.

Many transfers will originate from a timesharing system connected to a
packet switched network.  ZMODEM features allow simple, efficient
implementation on a wide variety of timesharing hosts.

File transfers begin immediately regardless of which program is started
first, without the 10 second delay associated with XMODEM.


7.3  Integrity and Robustness

Once a ZMODEM session is begun, all transactions are protected with 16 bit
CRC. (Except for the CAN-CAN-CAN-CAN-CAN abort sequence) Complex proprietary techniques such as Cybernetic Data
Recovery(TM)  (Unique to Professional-YAM and PowerCom) are not needed for reliable transfers.

A security challenge mechanism guards against "Trojan Horse" messages.

7.4  Ease of Implementation

ZMODEM accommodates a wide variety of systems:

 + Microcomputers that cannot overlap disk and serial i/o

 + Microcomputers that cannot overlap serial send and receive

 + Computers and/or networks requiring XON/XOFF flow control

 + 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. (Streaming strateges are discussed in coming chapters)

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.


8.  ZMODEM REQUIREMENTS

ZMODEM requires an 8 bit transfer medium.  ZMODEM escapes network control
characters to allow operation with packet switched networks.  In general,
ZMODEM operates over any path that supports XMODEM, and over some that
don't.

To support full streaming  (With XOFF and XON, or out of band flow control such as X.25 or CTS), the transmisson path should either assert
flow control or pass full speed transmission without loss of data.

8.1  File Contents

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.

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.

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 accomodate CRT displays that cannot
overstrike.  A text line is terminated by a CR/LF (015, 012) sequence, or
by a NL (012) character.  The sending program may use the ZCNL bit to
force the receiving program to convert the received end of line to its
local end of line convention.

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.

N.B.: Files that have been translated in such a way as to modify their
length cannot be updated with the ZCRECOV Conversion Option.  ZCRECOV
allows interrupted transfers to be resumed without loss of data.


9.  ZMODEM BASICS

9.1  Packetization

ZMODEM frames differ somewhat from X/YMODEM blocks.  X/YMODEM blocks are
not used for the following reasons:

 + Block numbers are limited to 256

 + No provision for variable length blocks

 + 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 X/YMODEM programs such as Professional-YAM and
   PowerCom overcome some of these weaknesses with clever proprietary
   code, but a stronger protocol is desired.

 + It is difficult to determine the beginning and ends of X/YMODEM blocks
   when line hits cause a loss of synchronization.  This precludes rapid
   error recovery.


9.2  Link Escape Encoding

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.(This and other constants are defined in the zmodem.h include file.
Please note that constants with a leading 0 are octal constants in C)

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 CAN characters to abort a ZMODEM session,
compatible with X/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.

By default, ZMODEM software currently 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 ZMODEM routines in zm.c accept an option to escape all control
characters, to allow operation with less transparent networks. The
routines also accept an option to escape only the ZDLE character, for
highest possible throughput.

9.3  Header

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:

 + A type byte (The frame types are cardinal numbers beginning with 0 to minimize
    state transition table memory requirements.Future extensions to ZMODEM may use the high order bits of the type
    byte to indicate thread selection.)

 + Four bytes of data indicating flags and/or numeric quantities depending
   on the frame type

     Figure 1.  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

9.3.1  Binary Header
A binary header is only sent by the sending program to the receiving
program.

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 will follow depending on the frame type.

The function zsbhdr transmits a binary header. The function zgethdr
receives a binary or hex header.

    Figure 2.  Binary Header
     * ZDLE A TYPE F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2


9.3.2  HEX Header
The receiver sends responses in hex headers.  The sender also uses hex
headers when they are not followed by binary data subpackets.

Hex encoding accomodates XON/XOFF flow control.  The hex header receiving
routine ignores flow control characters.

Use of Kermit style encoding for control and paritied characters was
considered and rejected because of increased possibility of interacting
with some timesharing systems's 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. Except for header types
that imply data subpackets to follow, a HEX header may be used in place of
a binary header wherever convenient.

A hex header begins with the sequence ZPAD, ZPAD, ZDLE, ZHEX.  The zgethdr
routine synchronizes with the ZPAD-ZDLE sequence.  The extra ZPAD allows
other parts of the program to detect a ZMODEM header and then call zgethdr
to receive the header.

The type byte, the four position/flag bytes, and the CRC thereof are sent
in hex using the character set 01234567890abcdef.  Upper case hex digits
are not allowed; they false trigger X/YMODEM programs.

A carriage return, line feed, and XON (XON is not sent after a ZFIN header, to allow clean session cleanup) are appended to the HEX header
but are not strictly a part of it.  The CR/LF aids debugging from
printouts.  The XON releases the sender from spurious XOFF flow control
characters generated by line noise, a common occurrence.

0 or more ASCII Encoded data subpackets will follow depending on the frame
type.

The function zshhdr sends a hex header.

     Figure 3.  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.)

9.4  Binary Data Subpackets

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 4800 bps, 1024 above 4800
bps or when the data link is known to be relatively error free.  Except
for the last subpacket in a file, (Or file segment if a sparse file is being processed) lengths should be a power of two.

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 ZDLE encoded CRC bytes.  The CRC accumulates the data bytes and
frameend.

The function zsdata sends a data subpacket.  The function zrdata receives
a data subpacket.

9.5  ASCII Encoded Data Subpacket

The format of ASCII Encoded data subpackets is not currently specified.
These would be used for server commands, or main transfers in 7 bit
environments.


10.  PROTOCOL TRANSACTION OVERVIEW

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. (Special considerations apply when sending commands)


10.1  Session Startup

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 "rzr" 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
as a list of the files requested, etc.

Then the sender may send a ZRQINIT header.  The ZRQINIT header causes a
previously started receive program to send its ZRINIT 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 B00 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 X/YMODEM
protocol.  Note: With ZMODEM and YMODEM Batch, 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 ZRINIT
header to initiate ZMODEM file transfers, or a ZCHALLENGE header to verify
the sending program.  The receive program resends its header at response
time (default 10 second) intervals for a suitable period of time (40
seconds total) before falling back to X/YMODEM protocol.

If the receiving program receives a ZRQINIT header, it resends the ZRINIT
header.  If the sending program receives the ZCHALLENGE header, it places
the data in ZP0...ZP3 in an answering ZACK header.

If the receiving program receives a ZRINIT header, it is an echo
indicating that the sending program is not operational.

Eventually the sending program correctly receives the ZRINIT header.

The sender may then send an optional ZSINIT frame to define the receiving
program's Attn sequence.  The receiver sends a ZACK header in response,
optionally containing the serial number of the receiving program, or 0.

10.2  File Transmission

The sender then sends a ZFILE header with ZMODEM Conversion, Management,
and Transport options (See below, under ZFILE header type) 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 ZSKIP header, which makes the sender
proceed to the next file (if any) in the batch.

       If the receiver has a file with the same name and length,
       it may respond with a ZCRC header, which requires the
       sender to perform a CRC on the file and transmit the CRC in
       a ZCRC header.  The receiver uses this information to
       determine whether to accept the file or skip it.  This
       sequence is triggered by the ZMCRC Management Option. (The type of CRC has not been determined yet.  The obvious choice of
    the CRC-16 used to protect packets may not be optimum for detecting
    differences between long files.  The fact that the file lengths are
    identical may give some guidance to the selection of CRC)

A ZRPOS header from the receiver initiates transmission of the file data
starting at the offset in the file specified in the ZRPOS header.
Normally the receiver specifies the data transfer 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. (This does not apply to files that have been translated) 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 ZDATA binary header (with file position) followed by
one or more data subpackets.

The receiver compares the file position in the ZDATA header with the
number of characters successfully received to the file.  If they do not
agree, a ZRPOS error response is generated to force the sender to the
right position within the file.  (If the ZMSPARS option is used, the receiver instead seeks to the
position given in the ZDATA header)

A data subpacket terminated by ZCRCGO and CRC does not elicit a response
unless an error is detected; more data subpacket(s) follow immediately.

       ZCRCQ data subpackets expect a ZACK response with the
       receiver's file offset if no error, otherwise a ZRPOS
       response with the last good file offset.  Another data
       subpacket continues immediately.  ZCRCQ subpackets are
       not used if the receiver does not indicate FDX ability
       with the CANFDX bit.

ZCRCW data subpackets expect a response before the next frame is sent.
If the receiver does not indicate overlapped I/O capability with the
CANOVIO bit, or sets a buffer size, the sender uses the ZCRCW 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 ZCRCE data subpacket which does not elicit a response
except in case of error.

The sender sends a ZEOF 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 ZRINIT.  If the receiver has
not received all the bytes of the file, the receiver sends ZRPOS with
the current file offset, forcing the sender to resend the missing
data.  (If the receiver cannot properly close the file, a ZFERR header
is sent.)

       After all files are processed, any further protocol
       errors should not prevent the sending program from
       returning with a success status.


10.3  Session Cleanup

The sender closes the session with a ZFIN header.  The receiver
acknowledges this with its own ZFIN 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.

10.4  Session Cancel Sequence

If the receiving program has been receiving data in streaming mode,
the Attn sequence is executed to interrupt data transmission.  The
Cancel sequence of eight CAN characters (The trailing backspace characters attempt to erase the effects of the
    CAN characters if they are received by a command interpreter) and ten backspace
characters is sent.

       static char canistr{} = [
 24,24,24,24,24,24,24,24,8,8,8,8,8,8,8,8,8,8,0
       ];


11.  STREAMING TECHNIQUES / ERROR RECOVERY

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


11.1  Full Streaming with Sampling

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 Attn
sequence required.  The sender begins data transmission with a ZDATA
header and continuous ZCRCG data subpackets.  When the receiver
detects an error, it executes the Attn sequence and then sends a
ZRPOS 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. Any other character is ignored.  (The call to rdchk() in sz.c performs this function)

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 an error packet. (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.)

Then the receiver's response header is read and acted upon.  (The call to getinsync() in sz.c performs this function) A
ZRPOS header resets the sender's file offset to the correct position.
If a ZACK header with an adress that disagrees with the current
address, it is ignored, and another header is expected.  A ZFIN,
ZABORT, or TIMEOUT terminates the session; a ZSKIP terminates the
processing of this file.

The reverse channel is then sampled for the presence of another
header from the receiver. (If sampling is possible) 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 ZDATA
header followed by data subpackets.


11.2  Full Streaming with Reverse Interrupt

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 Attn sequence.
After executing the Attn sequence, the receiver sends a hex ZRPOS
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 sz.c program uses a
setjmp/longjmp call to catch the interrupt generated by the Attn
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, sz.c uses an Attn
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.


11.3  Full Streaming with a Sliding Window

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 reciever's Attn sequence to flush the
sender's interrupt buffer before sending the ZRPOS header.

11.4  Full Streaming over Error Free Channels

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.

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.  (One in 256 for escaping ZDLE, about two in 1024 for data subpacket CRC's)

11.5  Segmented Streaming

If the receiver cannot overlap serial and disk I/O, it uses the
ZRINIT frame to specify a buffer length which the sender will not
overflow.  The sending program sends a ZCRCW data subpacket and waits
for a ZACK 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.


12.  ATTENTION SEQUENCE

The receiving program sends the Attn sequence whenever it detects an
error and needs to interrupt the sending program.

The default Attn 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 Attn string is terminated with a null.

Two meta-characters perform special functions:

   + 335 (octal) Send a break signal

   + 336 (octal) Pause one second


13.  FRAME TYPES

The numeric values for the values shown in boldface are given in
zmodem.h.  Unused bits and unused bytes in the header (ZP0...ZP3) are
set to 0.

13.1  ZRQINIT

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.

13.2  ZRINIT

Sent by the receiving program. ZF0 and ZF1 contain the  bitwise or
of the receiver capability flags:
#define CANFDX 1 /* Receiver can send and receive simultaneously */
#define CANOVIO 2 /* Receiver can receive during disk I/O */
#define CANBRK 4 /* Rx can send a break signal */
#define CANCRY 8 /* Receiver can decrypt */

ZP0 and ZP1 contain the size of the receiver's buffer in bytes, or 0
if nonstop I/O is allowed.

13.3  ZSINIT

Sender sends capability flags (currently all 0) (none currently
defined) followed by a binary data subpacket terminated with ZCRCW.
The data subpacket contains the null terminated Attn sequence,
maximum length 32 bytes including the terminating null.

13.4  ZACK

Acknowedgement to a ZSINIT frame, ZCHALLENGE header, or ZCRCW data
subpacket.  ZP0 to ZP3 contain file offset.  The response to
ZCHALLENGE contains the same 32 bit number received in the ZCHALLENGE
header.

13.5  ZFILE

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 ZCBIN which overrides any other Conversion Option given to the
sender or receiver.


13.5.1 ZF0: Conversion Option
If the receiver does not recognize the Conversion Option, an
application dependent default conversion may apply.

ZCBIN "Binary" transfer - inhibit conversion unconditionally

ZCNL 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.  (Filtering RUBOUT, NULL, Ctrl-Z, etc)

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

13.5.2 ZF1: Management Option
If the receiver does not recognize the Management Option, the
file should be transferred normally.

ZMNEW Transfer file if destination file absent.  Otherwise,
     transfer file overwriting destination if the source file
     is newer or longer.

ZMCRC Compare the source and destination files.  Transfer if
     file lengths or file polynomials differ.

ZMAPND Append source file contents to the end of the existing
     destination file (if any).

ZMCLOB Replace existing destination file (if any).

ZTSPARS Special processing for sparse file; 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 (or possibly ZCRCQ) data subpacket
     and process the expected ZACK to insure no data is lost.

ZMDIFF Transfer file if destination file absent.  Otherwise,
     transfer file overwriting destination if files have
     different lengths or dates.

ZMPROT Protect destination file by transferring file only if
     the destination file is absent.

13.5.3 ZF2: Transport Option
If the receiver does not implement the particular transport
option, the file is copied without conversion for later
processing.

ZTLZW Lempel-Ziv compression.  Transmitted data will be
     identical to that produced by compress 4.0 operating on
     a computer with VAX byte ordering, using 12 bit
     encoding.

ZTCRYPT Encryption.  An initial null terminated string
     identifies the key.  Details to be determined.

ZTRLE Run Length encoding, Details to be determined.

A ZCRCW data subpacket follows with file name, file length,
modification date, and other information described in a later
chapter.

13.6  ZSKIP

Sent by the receiver in response to ZFILE, makes the sender skip to
the next file.

13.7  ZNAK

Indicates last header was garbled.  (See also ZRPOS).

13.8  ZABORT

Sent by receiver to terminate batch file transfers when requested by
the user.  Sender responds with a ZFIN sequence.  (Or ZCOMPL in case of server mode)

13.9  ZFIN

Sent by sending program to terminate a ZMODEM session. Receiver
responds with its own ZFIN.

13.10  ZRPOS

Sent by receiver to force file transfer to resume at file offset
given in ZP0...ZP3.

13.11  ZDATA

ZP0...ZP3 contain file offset. One or more data subpackets follow.

13.12  ZEOF

Sender reports End of File.  ZP0...ZP3 contain the ending file
offset.

13.13  ZFERR

Error in reading or writing file, protocol equivalent to ZABORT.

13.14  ZCRC

Request (receiver) and response (sender) for file polynomial.
ZP0...ZP3 contain file polynomial.

13.15  ZCHALLENGE

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.

13.16  ZCOMPL

Request now completed.

13.17  ZCAN

This is a pseudo frame type returned by gethdr() in response to a
Session Abort sequence.

13.18  ZFREECNT

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.

13.19  ZCOMMAND

ZCOMMAND is sent in a binary frame.  ZF0 contains 0 or ZCACK1 (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 received the command.

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 ZCACK1, 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
should display the command to the standard error output, then return
a ZCOMPL header.

14.  SESSION TRANSACTION EXAMPLES

14.1  A simple file transfer

A simple transaction, one file, no errors, no CHALLENGE, overlapped
I/O:

Sender        Receiver

"rzr"
ZRQINIT(0)
        ZRINIT
ZFILE
        ZRPOS
ZDATA data ...
ZEOF
        ZRINIT
ZFIN
        ZFIN
OO


14.2  Challenge and Command Download


Sender        Receiver

"rzr"
ZRQINIT(ZCOMMAND)
        ZCHALLENGE(rnd)
ZACK(rnd)
        ZRINIT
ZCOMMAND
        (Performs Command)
        ZCOMPL
ZFIN
        ZFIN
OO



15.  ZFILE FRAME FILE INFORMATION

ZMODEM sends the same file information with the ZFILE frame data
that YMODEM Batch sends in its block 0.

N.B.: Only the pathname (file name) part is mandatory.

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 f option to send the full relative
     pathname. The source drive designator (A:, B:, etc.) is not
     sent.

     Filename Considerations:

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

 + The receiver should accommodate file names in lower and
   upper case.

 + 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, an file name should
   be invented be the receiving program.

     If directories are included, they are delimited by /; i.e.,
     "subdir/foo" is acceptable, "subdirfoo" is not.

Length The file length and each of the succeeding fields are
     optional. (Fields may not be skipped) The length field is stored as a decimal string
     counting the number of data bytes in the file.

     With ZMODEM, the 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
     contents 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.

     Two Microsoft blunders complicate the use of modification dates
     in file transfers with MSDOS(TM) systems. The first is the
     lack of timezone standardization in MS-DOS.  A file's creation
     time can not be known unless the timezone of the system that
     wrote the file  (Not necessarily that of the transmitting system!) is known.  Unix solved this problem (for
     planet Earth, anyway) by stamping files with Universal Time
     (GMT).  Microsoft would have to include the timezone of origin
     in the directory entries, but does not.  Professional-YAM gets
     around this problem by using the z parameter which is set to
     the number of minutes local time lags GMT.  For files known to
     originate from a different timezone, the -zT option may be used
     to specify T as the timezone for an individual file transfer.

     The second problem is the lack of a separate file creation date
     in DOS.  Since some backup schemes used with DOS rely on the
     file creation date to select files to be copied to the archive,
     back-dating the file modification date could interfere with the
     safety of the transferred files.  For this reason,
     Professional-YAM does not modify the date of received files
     with the header information unless the d parameter is non zero.


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
     number should omit this field, or set it to 0.  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 two 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.


16.  PERFORMANCE RESULTS

16.1  Compatibility

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 marked economy of reverse channel bandwith
allows modems that dynamically partition bandwidth between the two
directions to operate at optimal speeds.

16.2  Throughput

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 program images to an IBM PC (4.7 mHz V20)
running YAMK 15.68 with table driven CRC calculation yielded a
throughput of about 17kb on a 19.2 kb direct connection.

16.3  Error Recovery

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 channel delay, as 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
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 loss.
Long bursts (such as pulse dialing noises) often require a timeout
error to restore the flow of data.


17.  PACKET SWITCHED NETWORK CONSIDERATIONS

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)
does 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 both
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.

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.


      TABLE 1.  Network and Flow Control Compatibility

_____________________________________________________________________________
|   Connectivity    |  Interactive|  XMODEM|  WXMODEM| SUPERKERMIT|  ZMODEM|
_____________________________________________________________________________
|___________________|_____________|________|_________|_____________|________|
|Direct Connect     |  YES        |  YES   |  YES    | YES         |  YES   |
|___________________|_____________|________|_________|_____________|________|
|Network, no FC     |  NO         |  YES   |  (4)    | (6)         |  (1)   |
|___________________|_____________|________|_________|_____________|________|
|Net, transparent FC|  YES        |  YES   |  YES    | YES         |  YES   |
|___________________|_____________|________|_________|_____________|________|
|Net, non-trans. FC |  YES        |  NO    |  NO(5)  | YES         |  YES   |
|___________________|_____________|________|_________|_____________|________|
|Network, 7 bit     |  YES        |  NO    |  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.



18.  PERFORMANCE COMPARISON TABLES


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

   TABLE 2.  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   |
____________________________________________________________________________
|_____________________|________|_______|______|________|_________|_________|
|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   |
|_____________________|________|_______|______|________|_________|_________|


   Figure 4.  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

 TABLE 3.  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 not 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.


         TABLE 4.  Protocol Checklist

_________________________________________________________________________
|Item                 XMODEM   WXMODEM  YMDM-k  YMDM-g  ZMODEM   SKermit|
_________________________________________________________________________
|IN SERVICE         |  1979  | 1986   | 1982   | 1985  | 1986  | 1985   |
|___________________|________|________|________|_______|_______|________|
|USER FEATURES      |        |        |        |       |       |        |
|User Friendly I/F  |  -     | -      | -      | -     | YES   | -      |
|Commands/batch     |  2*N   | 2*N    | 2      | 2     | 1     | 1(1)   |
|Commands/file      |  2     | 2      | 0      | 0     | 0     | 0      |
|Command Download   |  -     | -      | -      | -     | YES   | YES(6) |
|Menu Compatible    |  -     | -      | -      | -     | YES   | -      |
|Transfer Recovery  |  -     | -      | -      | -     | YES   | -      |
|File Management    |  -     | -      | -      | -     | YES   | -      |
|Security Check     |  -     | -      | -      | -     | YES   | -      |
|X/YMODEM Fallback  |  YES   | YES    | YES    | YES   | YES   | -      |
|___________________|________|________|________|_______|_______|________|
|COMPATIBILITY      |        |        |        |       |       |        |
|Dynamic Files      |  YES   | YES    | FAIL   | FAIL  | YES   | YES    |
|Packet SW NETS     |  -     | YES    | -      | -     | YES   | YES    |
|7 bit PS NETS      |  -     | -      | -      | -     | (8)   | YES    |
|Old Mainframes     |  -     | -      | -      | -     | (8)   | YES    |
|CP/M-80            |  YES   | YES    | YES    | -     | YES(9)| -      |
|___________________|________|________|________|_______|_______|________|
|ATTRIBUTES         |        |        |        |       |       |        |
|Reliability(5)     |  fair  | poor   | fair(5)| none  | BEST  | HIGH   |
|Streaming          |  -     | YES    | -      | YES   | YES   | YES    |
|Overhead(2)        |  7%    | 7%     | 1%     | 1%    | 1%    | 30%    |
|Faithful Xfers     |  -     | -      | YES(3) | YES(3)| YES   | YES    |
|Preserve Date      |  -     | -      | YES    | YES   | YES   | -      |
|___________________|________|________|________|_______|_______|________|
|COMPLEXITY         |        |        |        |       |       |        |                     
|CRC-16             |  -     | REQD   | REQD   | REQD  | REQD  | opt    |
|32 bit math        |  -     | -      | (3)    | (3)   | REQD  | -      |
|No-Wait Sample     |  -     | REQD   | -      | -     | opt   | REQD   |
|Ring Buffers       |  -     | REQD   | -      | -     | opt   | REQD   |
|XMODEM Similar     |  YES   | LOW    | HIGH   | HIGH  | LOW   | NONE   |
|Complexity         |  LOW(5)| MED    | LOW(5) | LOW   | MED   | HIGH   |
|___________________|________|________|________|_______|_______|________|
|EXTENSIONS         |        |        |        |       |       |        |
|Server Operation   |  -     | -      | -      | -     | YES(4)| YES    |
|Multiple Threads   |  -     | -      | -      | -     | future| -      |
_________________________________________________________________________

NOTES:
(1) Server mode only
(2) Character count, binary file, transparent channel
(3) 32 bit math needed for accurate transfer (no garbage added)
(4) AutoDownload operation
(5) X/YMODEM gives high reliability with special data recovery
alogrithyms.  These proprietary reliability enhancemnets add greatly
to software complexity
(6) Server commands only
(7) No provision for transfers across time zones
(8) Future enhancement provided for
(9) With Segmented Streaming
WXMODEM: XMODEM derivative with data encoding and Windowing
FAST: File transfer protocol requiring end-to-end 8-bit transparent,
error free communications.



19.  FUTURE EXTENSIONS

Future extensions include:

   + Compatibility with 7 bit networks

   + Server/Link Level operation: An END-TO-END error corrected
     program to program session is required for financial and other
     sensitive applications.

   + 32 bit CRC: for sensitive applications

   + Multiple independent threads

   + Encryption

   + Compression

   + File Comparision

   + Selective transfer within a file (e.g., modified segments of a
     database file).


20.  REVISIONS

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.


21.  MORE INFORMATION

More information may be obtained by calling TeleGodzilla at
503-621-3746.

UUCP sites can obtain the nroff/troff source to this file with
   uucp omen!/usr/caf/public/zmodem/zmodem.mm /tmp

A continually updated list of available files is stored in
/usr/spool/uucppublic/FILES.

The following L.sys line allows UUCP to call site "omen" via Omen's
bulletin board system "TeleGodzilla".  TeleGodzilla uses Pro-YAM in
host operation.

In response to TeleGodzilla's "Name Please:" uucico gives the
Pro-YAM "link" command as a user name. 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 logs in as uucp.


omen Any ACU 1200 1-503-621-3746 e:--e: link d: Giznoid n:--n: uucp



22.  ZMODEM PROGRAMS

A copy of this document, a demonstration version of
Professional-YAM, a flash-up tree structured help file and
processor, are available in ZMODEM.ARC on TeleGodzilla.  This file
must be unpacked with ARC-E.COM compatible with ARC5x files.  ARC-
E.COM is also available on TeleGodzilla.

ZCOMM, a "user supported" communications program, also includes
ZMODEM as well as Omen's highly acclaimed XMODEM and YMODEM support.

Source code and manual pages for UNIX programs are available on
TeleGodzilla in RZSZ1.SHQ and RZSZ2.SHQ, squeezed "shell archives".
To use these files, unsqueeze them with YAMDEMO's "usq" command,
upload them to Unix, and then execute them as shell scripts to break
them into the program and documentation source files.  More detailed
instructions may be found in Chapter 8 of the Professional-YAM
User's manual. Most Unix like systems are supported, including V7,
Sys III, 4.x BSD, SYS V, Idris, Coherent, and Regulus.

22.1  Adding ZMODEM to DOS Programs

22.1.1 YAMDEMO.EXE
DOS programs such as bulletin boards may call ZCOMM.EXE or
YAMDEMO.EXE with the DOS EXEC function to support fast, reliable
ZMODEM file transfers. This method allows program developers to add
ZMODEM support with a minimum of software development at the expense
of higher memory utilization than built-in routines.

YAMDEMO.EXE beginning with Version 15.61 include an xmodem command
which performs the following functions:

 + Sets restricted opertaion, restricting pathnames and disallowing
   modification of existing files

 + Causes error messages to be sent to the modem

 + Forces an exit after the command is finished

When YAMDEMO.EXE is used in this way, the default setup file
DEMOPHON.T should be overriden with the DOS environment variable
PHONES:
        set PHONES=C:/newphone.t
where newphone.t contains
setup      return
(other commands may be added as necessary).

If a comm port other than COM1 is used, the DPORT environment
variable should be set:
       set DPORT=2

The Online help processor included in ZMODEM.ARC and the
Professional-YAM User's Manual contain other useful information that
applies to YAMDEMO.EXE.

YAMDEMO.EXE unmodified may be copied and used without licensing or
other liability.  Omen Technology requests that YAMDEMO.EXE be
distributed only in conjunction with all the files included in
ZMODEM.ARC, as distributed by Omen, with no files deleted.


22.1.2 DSZ.EXE
DSZ is a small program that supports XMODEM, YMODEM, and ZMODEM file
transfers.  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 filea and the second (if sent) to
fileb. This form of dsz 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.


23.  YMODEM PROGRAMS

Unix programs supporting the YMODEM protocol are available on
TeleGodzilla in the "upgrade" subdirectory as RBSB.SHQ (a SQueezed
shell archive).  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 YMODEM 1k packets and YMODEM batch 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 and MEX-PC also support some of
the YMODEM extensions.

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
     Modem (TeleGodzilla): 503-621-3746
     Usenet: ...!tektronix!reed!omen!caf
     Compuserve: 70007,2304
     Source: TCE022

