


           The ZMODEM Inter Application        File Transfer Protocol

                              Chuck Forsberg

                           Omen        Technology Inc


                    Copyright 1997 Omen        Technology INC
                           All Rights Reserved





                       Omen Technology Incorporated
                      The High Reliability Software

                     10255 NW Old Cornelius Pass Road
                          Portland Oregon 97231

                           http://www.omen.com





































Chapter        0              Rev Jan-19-95  Typeset 7-15-97                         1






Chapter        0                     ZMODEM Protocol                                 2



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.

This document covers the technical details of the public domain        ZMODEM
protocol.  It does not cover copyrighted Extensions thereto.


2.  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:

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





Chapter        2              Rev Jan-19-95  Typeset 7-15-97                         2








Chapter        2                     ZMODEM Protocol                                 3



   o Lack of public domain documentation and example programs have kept
     proprietary protocols such        as Relay, Blast, DART, and others tightly
     bound to the fortunes of their suppliers.        These protocols        have not
     benefited from public scrutiny of their design features.

   o Link level        protocols such as X.25,        X.PC, and MNP 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 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.[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.










__________

 1. Some Kermit        programs support run length encoding.




Chapter        2              Rev Jan-19-95  Typeset 7-15-97                         3








Chapter        2                     ZMODEM Protocol                                 4



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 Cybernetic Data Recovery(TM)[2] improve reliability,
but are        not universally        available.  Some of the        XMODEM mutant protocols
have significant design        flaws of their own.

 o XMODEM-k uses 1024 byte blocks to reduce the        overhead from transmission
   delays by 87        per cent compared to XMODEM, but network delays        still
   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 YMODEM 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 YMODEM-g 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 WXMODEM, SEAlink, and MEGAlink 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
OverThruster(TM) and OverThruster II(TM).  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.



__________

 2. Unique to DSZ, ZCOMM, Professional-YAM and PowerCom




Chapter        2              Rev Jan-19-95  Typeset 7-15-97                         4








Chapter        2                     ZMODEM Protocol                                 5



3.  ZMODEM Protocol Design Criteria

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

3.1  Ease of Use

 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.

 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  Throughput

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 Direct modem to modem communications with high error rate

Unlike Sliding Windows Kermit, ZMODEM is not optimized for optimum


__________

 1. Provided the transmission medium accommodates X/YMODEM.




Chapter        3              Rev Jan-19-95  Typeset 7-15-97                         5








Chapter        3                     ZMODEM Protocol                                 6



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.


3.3  Integrity and Robustness

Once a ZMODEM session is begun,        all transactions are protected with 16 or
32 bit CRC.[2] Complex proprietary techniques such as Omen Technology's
Cybernetic Data        Recovery(TM)[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).  32        bit CRC        is considered mandatory        for high speed and/or high
volume transfers of sensitive data.

A security challenge mechanism guards against "Trojan Horse" messages
written        to mimic legitimate command or file downloads.

3.4  Ease of Implementation

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




__________

 2. Except for the CAN-CAN-CAN-CAN-CAN abort sequence which requires five
    successive CAN characters.

 3. Unique to Professional-YAM,        ZCOMM, and PowerCom




Chapter        3              Rev Jan-19-95  Typeset 7-15-97                         6








Chapter        3                     ZMODEM Protocol                                 7



 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.

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 for the public domain under a Telenet contract.  The
ZMODEM protocol        descriptions are public        domain.         No licensing, trademark,
or copyright restrictions apply        to the use of the protocol and the ZMODEM
name.


4.  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?  WXMODEM,
SEAlink, MEGAlink and some other protocols add binary byte(s) to indicate
the block number.



__________

 4. Streaming strategies are discussed in coming chapters.




Chapter        4              Rev Jan-19-95  Typeset 7-15-97                         7








Chapter        4                     ZMODEM Protocol                                 8



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


__________

 1. Without stopping for a response

 2. The        WINDOW is the data in transit between sender and receiver.

 3. For        example, when SuperKermit encounters certain errors, the wndesr



Chapter        4              Rev Jan-19-95  Typeset 7-15-97                         8








Chapter        4                     ZMODEM Protocol                                 9



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.
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) frame
headers, the sending program can send a        hex "invitation        to receive"
sequence to activate the receiver without crashing the remote application
with unexpected        control        characters.  ZMODEM's ability to accept        options
from both the sender and receiver further simplify application
development.

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


__________________________________________________________________________

    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 Jan-19-95  Typeset 7-15-97                         9








Chapter        4                     ZMODEM Protocol                                10



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.


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.

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.

ZMODEM FRAME A ZMODEM frame consists of        a header and 0 or more data
        subpackets.

ZMODEM HEADER All ZMODEM headers contain a type        byte, header information,
        and CRC.

ZMODEM SUBPACKET A ZMODEM subpacket is a stream        of 0 to        1024 data bytes
        terminated by a        flag sequence and CRC.









Chapter        6              Rev Jan-19-95  Typeset 7-15-97                        10








Chapter        6                     ZMODEM Protocol                                11



6.  ZMODEM REQUIREMENTS

Standard 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  File Contents

6.1.1  Binary Files
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.

6.1.2  Text Files
When 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         ASCII End of Line
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 ZCNL bit to force the
receiving program to convert the received end of line to its local end of
line convention.[3]


__________

 1. This document does not describe ZMODEM-90(TM) extensions for operation
    in 7 bit environments.

 2. With XOFF and XON, or out of band flow control such        as X.25        or CTS

 3. Files that have been translated in such a way as to        modify their



Chapter        6              Rev Jan-19-95  Typeset 7-15-97                        11








Chapter        6                     ZMODEM Protocol                                12



7.  ZMODEM BASICS

7.1  Packetization

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



__________________________________________________________________________

    length cannot be updated with the ZCRECOV Conversion Option.

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




Chapter        7              Rev Jan-19-95  Typeset 7-15-97                        12








Chapter        7                     ZMODEM Protocol                                13



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

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  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:

 o A type byte

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









__________

 2. ZMODEM-90 extensions control the set of characters that are        escaped.




Chapter        7              Rev Jan-19-95  Typeset 7-15-97                        13








Chapter        7                     ZMODEM Protocol                                14



                   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

7.3.1  16 Bit CRC Binary Header
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 C function zsbhdr transmits        a binary header.  The C        function zgethdr
receives a binary or hex header.

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


7.3.2  32 Bit CRC Binary Header
A "32 bit CRC" Binary header is        similar        to a Binary Header, except the
ZBIN (A) character is replaced by a ZBIN32 (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.


7.3.3  32 Bit CRC Binary Header        - RLE
A "32 bit CRC -        RLE" Binary header is similar to a Binary Header, except
the ZBIN (A) character is replaced by a        ZBINR32        (D) character, and four
characters of CRC are sent.  0 or more RLE packed binary data subpackets
with 32        bit CRC        will follow depending on the frame type.

The common variable Txfcs32 may        be set TRUE for        32 bit CRC iff the
receiver indicates the capability with the CANFC32 bit.         The zgethdr,
zsdata and zrdata C functions automatically adjust to the type of Frame





Chapter        7              Rev Jan-19-95  Typeset 7-15-97                        14








Chapter        7                     ZMODEM Protocol                                15



Check Sequence being used.
                   Figure 3.  32 Bit CRC Binary        Header
     ZPAD ZDLE C TYPE F3/P0 F2/P1 F1/P2        F0/P3 CRC-1 CRC-2 CRC-3        CRC-4


7.3.4  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 protects the reverse channel from random control characters.
The hex        header receiving routine ignores parity.[3]

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 subpacket
follows        a HEX header, it is protected with CRC-16.

A hex header begins with the sequence ZPAD, ZPAD, ZDLE,        ZHEX.  The zgethdr
routine        synchronizes with the ZPAD-ZDLE        sequence.  The extra ZPAD
character allows the sending program to        scan for a ZPAD        character, to
detect a header        (indicating an error condition)        and then call zgethdr 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.

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 receiver carefully checks hex headers for violations of this format.
Since the constraints and redundancy of        this hex encoding detect many
patterns of errors, especially missing characters, a hex header        with 32
bit CRC        has not        been defined.

The CR/LF aids debugging from printouts, and helps overcome certain
operating system related problems.  The        LF is sent with        8th bit        set to aid
the receiver in        checking for 7 bit paths.

An XON character is appended to        all HEX        headers        except ZACK and        ZFIN.  The
XON releases the sender        from spurious XOFF flow        control        characters


__________

 3. Except to detect the presence of a 7-bit transmission path.




Chapter        7              Rev Jan-19-95  Typeset 7-15-97                        15








Chapter        7                     ZMODEM Protocol                                16



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.  The receiver may or
may not        receive        the XON        character depending on the flow        control
arrangements.

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

The C function zshhdr sends a hex header.

                          Figure 4.  HEX Header

 ZPAD ZPAD ZDLE        B TYPE F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2 CR LF+128 XON

(TYPE, F3...F0,        CRC-1, and CRC-2 are each sent as two hex digits.)


7.4  Binary Data Subpackets

Binary data subpackets immediately follow the associated binary        header
packet.         A binary data subpacket 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 C function zsdata sends a data subpacket.  The C function zrdata
receives a data        subpacket.

7.5  RLE Binary        Data Subpackets

Data subpackets        following a ZBINR32 header are run length encoded to
reduce transmission time on files with favorable characteristics.  Special
attention is paid to moderately        long runs of spaces commonly found in text
files.

The expression of RLE technology in ZMODEM is copyrighted by Omen
Technology Inc.        Licensing conditions are set forth in the source code.
Source code for        the RLE        routines is available from Omen        Technology INC.


__________

 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.




Chapter        7              Rev Jan-19-95  Typeset 7-15-97                        16








Chapter        7                     ZMODEM Protocol                                17



7.6  RLE Binary        Data Subpackets        with 8th Bit Quoting

A similar application of RLE encoding coupled with Kermit style        8th bit
quoting        is used        for data packets compatible with 7 bit transmission paths.
This is        a Copyrighted ZMODEM-90        extension available for        licensing from
Omen Technology        INC.

7.7  ASCII Encoded Data        Subpacket

ASCII encoded packed data subpackets send 4 bytes of binary data in 5
bytes of printing characters.  This format is ideal for        sending        compressed
files over 7 bit paths.         This is a Copyrighted ZMODEM-90 extension
available for licensing        from Omen Technology INC.


8.  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.[1]

It goes        without        saying that both the transmitter and receiver should check
carrier        detect or equivalent signals often enough to properly exit in the
event of a disconnect.        Keep in        mind that in ZMODEM's most efficient mode
of operation, no response is expected from the receiver        during the entire
file transfer except for error correction!

8.1  Session Startup

To start a ZMODEM file transfer        session, the sending program is        called
with the names of the desired file(s) and possible options.

The sending program may        send the string        "rz\r" to invoke the receiving
program        from a possible        command        mode (DOS, Unix, VMS command prompt,
etc.).        The "rz" followed by carriage return invokes the rz program
(ZMODEM        receive) or command if it were not already active.  This sequence
is invisible to        terminal programs because the "rz\r" is        overlaid.

The sender may then display a message intended for human consumption, such
as a list of the files requested, etc.        If a ZMODEM receiver is        active,
this message will be ignored.

Then the sender        sends a        ZRQINIT        header.         The ZRQINIT header causes a
previously started receive program to send its ZRINIT header without
delay.


__________

 1. Special considerations apply when sending commands.




Chapter        8              Rev Jan-19-95  Typeset 7-15-97                        17








Chapter        8                     ZMODEM Protocol                                18



In an interactive or conversational mode, the receiving        application may
monitor        the data stream        for ZDLE.  The following characters may        be
compared to 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 YMODEM
protocol.[2] 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 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 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 active.

Eventually the sending program correctly receives the ZRINIT header.  The
sending        program        reads the information contained        in the ZRINIT header to
ascertain the receiving        program's feature set and/or flags.  This is the
only time that the information in the ZRINIT header is used.

The sender may then send an optional ZSINIT frame to define the        receiving
program's Attn sequence, or to specify complete        control        character
escaping.[3]

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 ZACK header in response, containing either        the serial


__________

 2. Allowing this fallback to XMODEM or        YMODEM compromises reliability and
    is not recommended as a default.

 3. 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 Jan-19-95  Typeset 7-15-97                        18








Chapter        8                     ZMODEM Protocol                                19



number of the receiving        program, or 0.

8.2  File Transmission

The sender then        sends a        ZFILE header with ZMODEM Conversion, Management,
and Transport options[4] followed by a ZCRCW data subpacket containing the
file name, file        length,        modification date, and other information identical
to that        used by        YMODEM.

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.         The "Number of        Files
Remaining" for this file is placed in the value        of the header.

The receiver may respond with a        ZFERR header, indicating an error in
attempting to open the file.  Possible errors include write protected
file, disk error, out of buffers.  The "Number of Files        Remaining" for
this file is placed in the value of the        header.

       The receiver has        a file with the        same name and length, may
       respond with a ZCRC 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 ZCRC header.[5] 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 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 to begin begin at
offset 0 in the        file.
       The receiver may        start the transfer further down        in the
       file.[6]        This allows a file transfer interrupted        by a loss


__________

 4. See        below, under ZFILE header type.

 5. The        crc is initialized to 0xFFFFFFFF.  A byte count        of 0 implies the
    entire file.

 6. The        sending        program's operating system file        structure may require this
    offset to be an integral multiple of the file system record        size.  A
    good rule of thumb is to round the offset down to the nearest multiple



Chapter        8              Rev Jan-19-95  Typeset 7-15-97                        19








Chapter        8                     ZMODEM Protocol                                20



       of carrier or system crash to be        completed on the next
       connection without requiring the        entire file to be
       retransmitted.[7] 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 start a
new frame at the correct position within the file.[8]

A data subpacket terminated by ZCRCG 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. [9] The receiver compares        this


__________________________________________________________________________

    of 1024.

 7. This does not apply        to files that have been        translated.

 8. If the ZMSPARS option is used, the receiver        instead        seeks to the
    position given in the ZDATA        header.




Chapter        8              Rev Jan-19-95  Typeset 7-15-97                        20








Chapter        8                     ZMODEM Protocol                                21



number with the        number of characters received.        If this        comparision
indicates the receiver has received all        of the file, the receiver
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 ignores the ZEOF because a new ZDATA is
coming.         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.


8.3  Session Cleanup

The sender closes the session with a ZFIN header.  The receiver
acknowledges this with its own ZFIN header.

At this        point, all the work has        been completed successfully, but it
is possible for        any of these packets to        be lost.  Considering that
the sender will        not close the session until all        work has been
finished (and acknowledged), the consideration is now how to exit
cleanly        (if possible) but at least to exit unconditionally.

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  Session Abort Sequence

If the receiver        is receiving data in streaming mode, the Attn
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
       };



__________________________________________________________________________

 9. As determined by the offset        within the file        at the time the        sending
    program encountered        end-of-file.




Chapter        8              Rev Jan-19-95  Typeset 7-15-97                        21








Chapter        8                     ZMODEM Protocol                                22



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


9.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.[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 sz.c        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 sz.c performs this function.



Chapter        9              Rev Jan-19-95  Typeset 7-15-97                        22








Chapter        9                     ZMODEM Protocol                                23



A ZRPOS        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 ZACK header with        an address that        disagrees
with the sender        address, it is ignored,        and the        sender waits for
another        header.         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.[4] if        one is detected, the getinsync() C
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.


9.1.1  Window Management
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 sz        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 Jan-19-95  Typeset 7-15-97                        23








Chapter        9                     ZMODEM Protocol                                24



9.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() C
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.


9.3  Full Streaming with 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        receiver's Attn        sequence to flush the
sender's interrupt buffer before sending the ZRPOS header.






__________________________________________________________________________

    control with XON and XOFF characters and pass XON characters that
    violate flow control, the receiving        program        should have a revision
    date of May        9 or later.




Chapter        9              Rev Jan-19-95  Typeset 7-15-97                        24








Chapter        9                     ZMODEM Protocol                                25



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


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



__________

 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 Jan-19-95  Typeset 7-15-97                        25








Chapter        10                     ZMODEM Protocol                                26



Two meta-characters perform special functions:

   o \335 (octal) Send a break signal

   o \336 (octal) Pause        one second


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

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

11.2  ZRINIT

Sent by        the receiving program.        ZF0 and        ZF1 contain the         bitwise or
of the receiver        capability flags:
#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        CANRLE          010        /* Receiver can        decode RLE */
#define        CANLZW          020        /* Receiver can        uncompress LZW */
#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  ZSINIT

The Sender sends flags followed        by a binary data subpacket terminated
with ZCRCW.

/* 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 Jan-19-95  Typeset 7-15-97                        26








Chapter        11                     ZMODEM Protocol                                27



The data subpacket contains the        null terminated        Attn sequence,
maximum        length 32 bytes        including the terminating null.

11.4  ZACK

Acknowledgment to a ZSINIT frame, ZCHALLENGE header, ZCRCQ 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.

11.5  ZFILE

This frame denotes the beginning of a file transmission        attempt.
ZF0, ZF1, and ZF2 may contain options.        ZRWOVR,        if present, contain
the sender's override rx window        size/256.  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.  A ZCBIN from        the sender overrides any other Conversion
Option given to        the receiver except ZCRESUM.  A        ZCBIN from the
receiver overrides any other Conversion        Option sent by the sender.


11.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.[1]

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


__________

 1. Filtering RUBOUT, NULL, Ctrl-Z, etc.




Chapter        11              Rev Jan-19-95  Typeset 7-15-97                        27








Chapter        11                     ZMODEM Protocol                                28



     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        ZF1: Management        Option
If the receiver        does not recognize the Management Option, the
file should be transferred normally.

The ZMSKNOLOC 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 ZMMASK) define the following set of
mutually exclusive management options.

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

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.

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

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

ZTRLE Run Length encoding.  The        transmitter will use RLE
     encoded data subpackets.  The ZTRLE bit is        used as        a



Chapter        11              Rev Jan-19-95  Typeset 7-15-97                        28








Chapter        11                     ZMODEM Protocol                                29



     display flag, the actual encoding choice is indicated by
     the frame type.

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

11.5.4        ZF3: Extended Options
The Extended Options are bit encoded.

ZTSPARS        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  ZSKIP

Sent by        the receiver in        response to ZFILE, makes the sender skip to
the next file.        The "Number of Files Remaining"        for this file is
placed in the value of the header.

11.7  ZNAK

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

11.8  ZABORT

Sent by        receiver to terminate batch file transfers when        requested by
the user.  Sender responds with        a ZFIN sequence.[2]

11.9  ZFIN

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

11.10  ZRPOS

Sent by        receiver to force file transfer        to resume at file offset
given in ZP0...ZP3.  Some sending programs restrict acceptable ZRPOS
offsets.  Offsets of transmitted subpackets are        expected to be
acceptable.




__________

 2. Or ZCOMPL in case of server        mode.




Chapter        11              Rev Jan-19-95  Typeset 7-15-97                        29








Chapter        11                     ZMODEM Protocol                                30



11.11  ZDATA

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

11.12  ZEOF

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

11.13  ZFERR

After receiving        a ZFILE        frame, but before the receiver sends ZRPOS,
ZFERR indicates        the output file        cannot be opened bcause        of an error
condition (write protected, illegal pathname, etc.).

Otherwise, indicates an        error in reading or writing file, protocol
equivalent to ZABORT.  The "Number of Files Remaining" for this        file
is placed in the value of the header.

11.14  ZCRC

Request        (receiver) and response        (sender) for file polynomial.
ZP0...ZP3 contain number of bytes (receiver) or        file polynomial
(sender).  Offset of segment to        checksum starts        at byte        6 of header,
or 0.[3] Number        of bytes and offset must be multiples of 1024.

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

11.16  ZCOMPL

Request        now completed.

11.17  ZCAN

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






__________

 3. Available with variable length headers.




Chapter        11              Rev Jan-19-95  Typeset 7-15-97                        30








Chapter        11                     ZMODEM Protocol                                31



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

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



12.  SESSION TRANSACTION EXAMPLES









Chapter        12              Rev Jan-19-95  Typeset 7-15-97                        31








Chapter        12                     ZMODEM Protocol                                32



12.1  A        simple file transfer

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


12.2  Challenge        and Command Download


Sender                    Receiver

"rz\r"
ZRQINIT(ZCOMMAND)
                    ZCHALLENGE(random-number)
ZACK(same-number)
                    ZRINIT
ZCOMMAND, ZDATA
                    (Performs Command)
                    ZCOMPL
ZFIN
                    ZFIN
OO


13.  ZFILE FRAME FILE INFORMATION

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

N.B.: The pathname (filename) field is mandatory.

Pathname The pathname (conventionally, the filename) 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
     Normally only the filename        stem (no directory prefix) is



Chapter        13              Rev Jan-19-95  Typeset 7-15-97                        32








Chapter        13                     ZMODEM Protocol                                33



     transmitted unless        the sender has selected        YAM's f        option to
     send the full absolute or relative        pathname, with directories
     indicated by a / character.  The source drive designator (A:,
     B:, etc.) usually is not sent.  The pathname/filename and the
     other fields must fit within the maximum packet or        subpacket
     length.  With ZMODEM this allows a        pathname length        of about
     1000 characters.  For obvious reasons, pathnames may not
     include embedded NULL characters.        The protocol itself does not
     require any further constraints on        pathnames other        than those
     stated above.

                         Filename Considerations
     Transferring files        between        disparate operating envrionments
     involves further considerations.

        o Filenames should be translated to lower case unless the
          sending system supports upper/lower case filenames.  This
          is a convenience for users of        systems        (such as Unix) which
          store        filenames in upper and lower case.  BE CIVILIZED,
          DON'T        SHOUT. THREE ROW KEYBOARDS WENT        OUT OF STYLE DECADES
          AGO.

        o The receiver should accommodate filenames in lower and
          upper        case.

        o When transmitting files between different operating
          systems, pathnames must be acceptable        to the receiving
          operating system.  If        not, transformations must be applied
          to make the filenames        acceptable.  One problem with
          filename transformations is the probability that multiple
          source filenames will        map to the same        destination
          filename.  If        the transformations are        unsuccessful, a        new
          filename may be invented be the receiving program.  The
          better approach is to        choose filenames that comply with
          the requirements of all relevant operating systems.  Long
          filenames and        filenames with non alphanumeric        characters
          will cause problems in many applications.

     If        directories are        included, they are delimited by        /; i.e.,
     "subdir/foo" is acceptable, [subdir]foo and "subdir\foo" are
     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.


__________

 1. Fields may not be skipped.




Chapter        13              Rev Jan-19-95  Typeset 7-15-97                        33








Chapter        13                     ZMODEM Protocol                                34



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


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.         The receiver's        use of this field is
     optional.        Programs which do not have a serial number should
     set it to 0, or omit it if        no fields follow.


Number of Files        Remaining Iff the number of files remaining is sent,
     a single space separates this field from the serial number
     field.  This field        is coded as a decimal number, and includes
     the current file.        Hence the last file in a batch will be
     represented as 1.        This field is an estimate, and incorrect
     values must not be        allowed        to cause loss of data.

     This value        must change for        each file to support reliable
     operation of ZSKIP        and ZFERR packets.  If the number of files
     (including        wild card expansions) is not counted, a        large number
     should be used so the number can be decremented once per file.



Chapter        13              Rev Jan-19-95  Typeset 7-15-97                        34








Chapter        13                     ZMODEM Protocol                                35



     The receiver's use        of this        field is optional.  If the Number of
     Bytes Remaining field is 0, the number of files is        not
     displayed by the receiver.


Number of Bytes        Remaining Iff the number of bytes remaining is sent,
     a single space separates this field from the number of files
     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 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.




14.  PERFORMANCE RESULTS

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

14.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 large binary files to an IBM PC (4.7 mHz



Chapter        14              Rev Jan-19-95  Typeset 7-15-97                        35








Chapter        14                     ZMODEM Protocol                                36



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





Chapter        14              Rev Jan-19-95  Typeset 7-15-97                        36








Chapter        15                     ZMODEM Protocol                                37



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

             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)              YES (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)
______________________________________________________________________________



Chapter        15              Rev Jan-19-95  Typeset 7-15-97                        37








Chapter        15                     ZMODEM Protocol                                38




|                    |                  |           |             |                   |             |
|1) ZMODEM can optim|ze        window siz| or burs| length f|r        fastest           |             |
|ransfers.            |                  |           |             |                   |             |
|2) Parity bits        must|be        encoded, s|owing bi|ary        trans|ers.           |             |
|3) Natural protocol|extension pos|ible        for|encoding |ata to 7 bits|             |
|4) Small WXMODEM wi|dow size may |ay allow|operation|                   |             |
|5) Some flow contro| codes are        no| escaped|in WXMODE|.                   |             |
|6) Kermit window si|e must be red|ced to a|oid        buffe| overrun.           |             |
|                    |                  |           |             |                   |             |
|                    |                  |           |             |                   |             |
|6.  REVISIONS            |                  |           |             |                   |             |
|                    |                  |           |             |                   |             |
|0-4-93        Changes        in u|e of ZSKIP        an| ZFERR h|aders, va|ue is the           |             |
|Number        of Files Rem|ining" for        th| current|file.  No|e        that           |             |
|revious versions of|the protocol |pec did |ot define|the data           |             |
|laced in the ZSKIP |nd        ZFERR head|rs.           |             |                   |             |
|                    |                  |           |             |                   |             |
|ecord type field in|filename fram|.           |             |                   |             |
|                    |                  |           |             |                   |             |
|-10-91        ZRINIT clari|ied.          |           |             |                   |             |
|                    |                  |           |             |                   |             |
|-7-90 Implementatio| dependent        re|triction| on        ZRPOS|offset noted.|             |
|eneral        cleanup.    |                  |           |             |                   |             |
|                    |                  |           |             |                   |             |
|2-14-88 ZMODEM        RLE |ompression        de|ined.  1|-14-88 Pa|cal source   |             |
|ode now available i| Phil Burn's |ibTerm v|.2.         6-24|88  An           |             |
|xception to the pre|iously uncond|tional Z|BIN        overr|de: a ZCRESUM|             |
|pecified by the rec|iver need not|be overr|dden by t|e        sender's   |             |
|CBIN.                    |                  |           |             |                   |             |
|                    |                  |           |             |                   |             |
|1-18-87 Editorial i|provements          |           |             |                   |             |
|                    |                  |           |             |                   |             |
|0-27-87 Optional fi|lds added for|number o| files re|aining to        be |             |
|ent and total numbe| of bytes rem|ining to|be sent. |                   |             |
|                    |                  |           |             |                   |             |
|7-31-1987 The recei|er        should ign|re a        ZEO| with an |ffset that   |             |
|oes not match the c|rrent file        le|gth.         Th| 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
1979 instead of        the actual August 1977.         More performance data was
added.



Chapter        16              Rev Jan-19-95  Typeset 7-15-97                        38








Chapter        16                     ZMODEM Protocol                                39



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.


17.  MORE INFORMATION

Please contact Omen Technology for typeset copies of this document.

Current        versions of this document are available        in Omen        Technology's
ZMODEM Developer's Collection ($89.00).         This collection includes
royalty        free C source code for XMODEM, YMODEM and ZMODEM protocols.

17.1  TeleGodzilla Bulletin Board

More information may be        obtained by calling the        TeleGodzilla
bulletin board at 503-621-3746.         TeleGodzilla supports 9600 (V32),
2400 and 1200 bps callers with automatic speed recognition.

Relevant files include YAMDEMO.ZIP, YAMHELP.ZIP, ZCOMMEXE.ZIP,



Chapter        17              Rev Jan-19-95  Typeset 7-15-97                        39








Chapter        17                     ZMODEM Protocol                                40



ZCOMMDOC.ZIP, ZCOMMHLP.ZIP.

Useful commands        for TeleGodzilla include "menu", "dir",        "sx file
(XMODEM)", "kermit sb file ...", and "sz file ...".


18.  ZMODEM PROGRAMS

TeleGodzilla and other bulletin        boards feature ZCOMM, 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 shareware program.        The
ZCOMM files include:

  o ZCOMMEXE.ZIP Executable files and beginner's telephone directory

  o ZCOMMDOC.ZIP "Universal Line Printer Edition" Manual

  o ZCOMMHLP.ZIP Tree structured Flash-UP help processor and
    database

Omen Technology        provides Professional-YAM, a full featured
communications program for DOS,        OS/2, Xenix and        Unix.  Source code
is available under license for various forms of        SYS V Unix.

Shareware C source code        and manual pages for the Unix/Xenix rz and
sz programs are        available on TeleGodzilla in RZSZ.ZIP.        also
available on TeleGodzilla.  Most Unix like systems are supported,
including V7, Sys III, 4.x BSD,        SYS V, Idris, Coherent,        and Regulus.

RZSZ.ZIP includes a ZCOMM/Pro-YAM/PowerCom script ZUPL.T to upload
the small (178 lines) YMODEM bootstrap program MINIRB.C        without        a
file transfer protocol.         MINIRB        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.  ZUPL.T directs the Unix
system to compile MINIRB, 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.


18.1  Adding ZMODEM to DOS Programs

DSZ is a small shareware program that supports XMODEM, YMODEM, and
ZMODEM file transfers.        DSZ 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



Chapter        18              Rev Jan-19-95  Typeset 7-15-97                        40








Chapter        18                     ZMODEM Protocol                                41



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.

Dsz 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 dsz may be found        in dsz.doc and the ZCOMM or
Pro-YAM        user manuals.


19.  CONSULTING        SERVICES

Consulting on ZMODEM is        available at $120.00 per hour.        A purchase
order for consulting services with prepayment for two hours
consulting is required before obtaining        services.  Questions about
ZMODEM may be directed to:

     Omen Technology Inc The High Reliability Software Post Office
     Box 4681 Portland OR 97208        VOICE: 503-614-0430 Modem: 503-617-
     1698 http://www.omen.com


20.  RELATED FILES

The following files should be consulted        by one studying        this
document:

YMODEM.DOC Describes the XMODEM, XMODEM-1k, and        YMODEM file transfer
        protocols.  Part of the        ZMODEM Developer's Collection.

zmodem.h Definitions for ZMODEM        manifest constants

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.

minirb.c A YMODEM bootstrap program, 178 lines.

DSZ.ZIP        Contains DSZ.COM, a shareware X/Y/ZMODEM subprogram,
        DESQview "pif" files for background operation in minimum
        memory,        and DSZ.DOC.




Chapter        20              Rev Jan-19-95  Typeset 7-15-97                        41








Chapter        20                     ZMODEM Protocol                                42



ZCOMM*.ZIP Archive files for ZCOMM, a powerful shareware
        communications program.




















































Chapter        20              Rev Jan-19-95  Typeset 7-15-97                        42








Chapter        20                     ZMODEM Protocol                                43



21.  ACKNOWLEDGMENTS


                 Copyright 1997        Omen Technology        INC
                        All Rights Reserved

The High Reliability Software(TM), TurboLearn Script Writer(TM),
Cybernetic Data        Recovery(TM), AutoDownload(TM),        ZMODEM-90(TM),
MobyTurbo(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 for the public domain under a Telenet contract.
The ZMODEM protocol descriptions are public domain.  No        licensing,
trademark, or copyright        restrictions apply to the use of the
protocol described here, or in using the ZMODEM        name to        identify
this protocol.

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.
































Chapter        21              Rev Jan-19-95  Typeset 7-15-97                        43












                              CONTENTS


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

 2.  WHY DEVELOP ZMODEM?..............................................         2

 3.  ZMODEM Protocol Design Criteria..................................         5
     3.1    Ease of Use...............................................         5
     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..............................................        11
     6.1    File Contents.............................................        11

 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    RLE        Binary Data Subpackets................................        16
     7.6    RLE        Binary Data Subpackets with 8th        Bit Quoting...........        17
     7.7    ASCII Encoded Data Subpacket..............................        17

 8.  PROTOCOL TRANSACTION OVERVIEW....................................        17
     8.1    Session Startup...........................................        17
     8.2    File Transmission.........................................        19
     8.3    Session Cleanup...........................................        21
     8.4    Session Abort Sequence....................................        21

 9.  STREAMING TECHNIQUES / ERROR RECOVERY............................        22
     9.1    Full Streaming with        Sampling..............................        22
     9.2    Full Streaming with        Reverse        Interrupt.....................        24
     9.3    Full Streaming with        Sliding        Window........................        24
     9.4    Full Streaming over        Error Free Channels...................        25
     9.5    Segmented Streaming.......................................        25

10.  ATTENTION SEQUENCE...............................................        25

11.  FRAME TYPES......................................................        26
     11.1   ZRQINIT...................................................        26
     11.2   ZRINIT....................................................        26
     11.3   ZSINIT....................................................        26
     11.4   ZACK......................................................        27
     11.5   ZFILE.....................................................        27
     11.6   ZSKIP.....................................................        29



                                  - i -












     11.7   ZNAK......................................................        29
     11.8   ZABORT....................................................        29
     11.9   ZFIN......................................................        29
     11.10  ZRPOS.....................................................        29
     11.11  ZDATA.....................................................        30
     11.12  ZEOF......................................................        30
     11.13  ZFERR.....................................................        30
     11.14  ZCRC......................................................        30
     11.15  ZCHALLENGE................................................        30
     11.16  ZCOMPL....................................................        30
     11.17  ZCAN......................................................        30
     11.18  ZFREECNT..................................................        31
     11.19  ZCOMMAND..................................................        31

12.  SESSION TRANSACTION EXAMPLES.....................................        31
     12.1   A simple file transfer....................................        32
     12.2   Challenge and Command Download............................        32

13.  ZFILE FRAME FILE INFORMATION.....................................        32

14.  PERFORMANCE RESULTS..............................................        35
     14.1   Compatibility.............................................        35
     14.2   Throughput................................................        35
     14.3   Error Recovery............................................        36

15.  PACKET SWITCHED NETWORK CONSIDERATIONS...........................        37

16.  REVISIONS........................................................        38

17.  MORE INFORMATION.................................................        39
     17.1   TeleGodzilla Bulletin Board...............................        39

18.  ZMODEM PROGRAMS..................................................        40
     18.1   Adding ZMODEM to DOS Programs.............................        40

19.  CONSULTING        SERVICES..............................................        41

20.  RELATED FILES....................................................        41

21.  ACKNOWLEDGMENTS..................................................        43


LIST OF        FIGURES


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

Figure 2.  16 Bit CRC Binary Header...................................        14

Figure 3.  32 Bit CRC Binary Header...................................        15




                                  - ii -












Figure 4.  HEX Header.................................................        16


LIST OF        TABLES


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















































                                 - iii -










           The ZMODEM Inter Application        File Transfer Protocol

                              Chuck Forsberg

                           Omen        Technology Inc


                                 ABSTRACT



The ZMODEM file        transfer protocol provides reliable file and command
transfers with complete        END-TO-END data        integrity between applications.
ZMODEM's 32 bit        CRC protects against errors that continue to sneak into
even the most advanced networks.

ZMODEM safeguards all data and supervisory information with effective
error detection.  Protocols without this protection were being developed
as late        as 1991.

ZMODEM rapidly transfers files,        particularly with buffered (error
correcting) modems, timesharing        systems, satellite relays, and wide area
packet switched        networks.  Optional LZW        and RLE        compression can        provide
even faster transfers.

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        production
programs have allowed dozens of        developers to upgrade their applications
with efficient,        reliable ZMODEM        file transfers with a minimum of effort.

Basic ZMODEM was developed for the public domain under a Telenet contract.
The basic ZMODEM protocol descriptions are public domain.  No licensing,
trademark, or copyright        restrictions apply to the use of the basic
protocol and the ZMODEM        name.










