xymodem.htm

X / Y Modem 协议 XMODEM/YMODEM PROTOCOL REFERENCE

    YAM(CP/M-86), YAM(CCPM-86), IMP (CP/M), KMD (CP/M), rz/sz (Unix, Xenix,
    VMS, Berkeley Unix, Venix, Xenix, Coherent, IDRIS, Regulus).  Commercial
    implementations include MIRROR, and Professional-YAM.[1] Communications







    Chapter 3







    X/YMODEM Protocol Reference    June 18 1988                              7



    programs supporting these extensions have been in use since 1981.

    The 1k block length (XMODEM-1k) described below may be used in conjunction
    with YMODEM Batch Protocol, or with single file transfers identical to the
    XMODEM/CRC protocol except for minimal changes to support 1k blocks.

    Another extension is the YMODEM-g protocol.  YMODEM-g provides batch
    transfers with maximum throughput when used with end to end error
    correcting media, such as X.PC and error correcting modems, including 9600
    bps units by TeleBit, U.S.Robotics, Hayes, Electronic Vaults, Data Race,
    and others.

    To complete this tome, edited versions of Ward Christensen's original
    protocol document and John Byrns's CRC-16 document are included for
    reference.

    References to the MODEM or MODEM7 protocol have been changed to XMODEM to
    accommodate the vernacular.  In Australia, it is properly called the
    Christensen Protocol.


    3.1  Some Messages from the Pioneer

    #: 130940 S0/Communications 25-Apr-85  18:38:47
    Sb: my protocol
    Fm: Ward Christensen 76703,302 [2]
    To: all

    Be aware the article[3] DID quote me correctly in terms of the phrases
    like "not robust", etc.

    It was a quick hack I threw together, very unplanned (like everything I
    do), to satisfy a personal need to communicate with "some other" people.

    ONLY the fact that it was done in 8/77, and that I put it in the public
    domain immediately, made it become the standard that it is.







    __________________________________________________________________________

     1. Available for IBM PC,XT,AT, Unix and Xenix

     2. Edited for typesetting appearance

     3. Infoworld April 29 p. 16




    Chapter 3







    X/YMODEM Protocol Reference    June 18 1988                              8



    I think its time for me to

    (1) document it; (people call me and say "my product is going to include
    it - what can I 'reference'", or "I'm writing a paper on it, what do I put
    in the bibliography") and

    (2) propose an "incremental extension" to it, which might take "exactly"
    the form of Chuck Forsberg's YAM protocol.  He wrote YAM in C for CP/M and
    put it in the public domain, and wrote a batch protocol for Unix[4] called
    rb and sb (receive batch, send batch), which was basically XMODEM with
       (a) a record 0 containing filename date time and size
       (b) a 1K block size option
       (c) CRC-16.

    He did some clever programming to detect false ACK or EOT, but basically
    left them the same.

    People who suggest I make SIGNIFICANT changes to the protocol, such as
    "full duplex", "multiple outstanding blocks", "multiple destinations", etc
    etc don't understand that the incredible simplicity of the protocol is one
    of the reasons it survived to this day in as many machines and programs as
    it may be found in!

    Consider the PC-NET group back in '77 or so - documenting to beat the band
    - THEY had a protocol, but it was "extremely complex", because it tried to
    be "all things to all people" - i.e. send binary files on a 7-bit system,
    etc.  I was not that "benevolent". I (emphasize > I < ) had an 8-bit UART,
    so "my protocol was an 8-bit protocol", and I would just say "sorry" to
    people who were held back by 7-bit limitations.  ...

    Block size: Chuck Forsberg created an extension of my protocol, called
    YAM, which is also supported via his public domain programs for UNIX
    called rb and sb - receive batch and send batch.  They cleverly send a
    "block 0" which contains the filename, date, time, and size.
    Unfortunately, its UNIX style, and is a bit weird[5] - octal numbers, etc.
    BUT, it is a nice way to overcome the kludgy "echo the chars of the name"
    introduced with MODEM7.  Further, chuck uses CRC-16 and optional 1K
    blocks.  Thus the record 0, 1K, and CRC, make it a "pretty slick new
    protocol" which is not significantly different from my own.

    Also, there is a catchy name - YMODEM.  That means to some that it is the
    "next thing after XMODEM", and to others that it is the Y(am)MODEM


    __________

     4. VAX/VMS versions of these programs are also available.

     5. The file length, time, and file mode are optional.  The pathname and
        file length may be sent alone if desired.




    Chapter 3







    X/YMODEM Protocol Reference    June 18 1988                              9



    protocol.  I don't want to emphasize that too much - out of fear that
    other mfgrs might think it is a "competitive" protocol, rather than an
    "unaffiliated" protocol.  Chuck is currently selling a much-enhanced
    version of his CP/M-80 C program YAM, calling it Professional Yam, and its
    for the PC - I'm using it right now.  VERY slick!  32K capture buffer,
    script, scrolling, previously captured text search, plus built-in commands
    for just about everything - directory (sorted every which way), XMODEM,
    YMODEM, KERMIT, and ASCII file upload/download, etc.  You can program it
    to "behave" with most any system - for example when trying a number for
    CIS it detects the "busy" string back from the modem and substitutes a
    diff phone # into the dialing string and branches back to try it.











































    Chapter 3







    X/YMODEM Protocol Reference    June 18 1988                             10



    4.  XMODEM PROTOCOL ENHANCEMENTS

    This chapter discusses the protocol extensions to Ward Christensen's 1982
    XMODEM protocol description document.

    The original document recommends the user be asked whether to continue
    trying or abort after 10 retries.  Most programs no longer ask the
    operator whether he wishes to keep retrying.  Virtually all correctable
    errors are corrected within the first few retransmissions.  If the line is
    so bad that ten attempts are insufficient, there is a significant danger
    of undetected errors.  If the connection is that bad, it's better to
    redial for a better connection, or mail a floppy disk.


    4.1  Graceful Abort

    The YAM and Professional-YAM X/YMODEM routines recognize a sequence of two
    consecutive CAN (Hex 18) characters without modem errors (overrun,
    framing, etc.) as a transfer abort command.  This sequence is recognized
    when is waiting for the beginning of a block or for an acknowledgement to
    a block that has been sent.  The check for two consecutive CAN characters
    reduces the number of transfers aborted by line hits.  YAM sends eight CAN
    characters when it aborts an XMODEM, YMODEM, or ZMODEM protocol file
    transfer.  Pro-YAM then sends eight backspaces to delete the CAN
    characters from the remote's keyboard input buffer, in case the remote had
    already aborted the transfer and was awaiting a keyboarded command.


    4.2  CRC-16 Option

    The XMODEM protocol uses an optional two character CRC-16 instead of the
    one character arithmetic checksum used by the original protocol and by
    most commercial implementations.  CRC-16 guarantees detection of all
    single and double bit errors,  all errors with an odd number of error
    bits, all burst errors of length 16 or less, 99.9969% of all 17-bit error
    bursts, and 99.9984 per cent of all possible longer error bursts.  By
    contrast, a double bit error, or a burst error of 9 bits or more can sneak
    past the XMODEM protocol arithmetic checksum.

    The XMODEM/CRC protocol is similar to the XMODEM protocol, except that the
    receiver specifies CRC-16 by sending C (Hex 43) instead of NAK when
    requesting the FIRST block.  A two byte CRC is sent in place of the one
    byte arithmetic checksum.

    YAM's c option to the r command enables CRC-16 in single file reception,
    corresponding to the original implementation in the MODEM7 series
    programs.  This remains the default because many commercial communications
    programs and bulletin board systems still do not support CRC-16,
    especially those written in Basic or Pascal.

    XMODEM protocol with CRC is accurate provided both sender and receiver



    Chapter 4                                     XMODEM Protocol Enhancements







    X/YMODEM Protocol Reference    June 18 1988                             11



    both report a successful transmission.  The protocol is robust in the
    presence of characters lost by buffer overloading on timesharing systems.

    The single character ACK/NAK responses generated by the receiving program
    adapt well to split speed modems, where the reverse channel is limited to
    ten per cent or less of the main channel's speed.

    XMODEM and YMODEM are half duplex protocols which do not attempt to
    transmit information and control signals in both directions at the same
    time.  This avoids buffer overrun problems that have been reported by
    users attempting to exploit full duplex asynchronous file transfer
    protocols such as Blast.

    Professional-YAM adds several proprietary logic enhancements to XMODEM's
    error detection and recovery.  These compatible enhancements eliminate
    most of the bad file transfers other programs make when using the XMODEM
    protocol under less than ideal conditions.


    4.3  XMODEM-1k 1024 Byte Block

    Disappointing throughput downloading from Unix with YMODEM[1] lead to the
    development of 1024 byte blocks in 1982.  1024 byte blocks reduce the
    effect of delays from timesharing systems, modems, and packet switched
    networks on throughput by 87.5 per cent in addition to decreasing XMODEM's
    3 per cent overhead (block number, CRC, etc.).

    Some environments cannot accept 1024 byte bursts, including some networks
    and minicomputer ports.  The longer block length should be an option.

    The choice to use 1024 byte blocks is expressed to the sending program on
    its command line or selection menu.[2] 1024 byte blocks improve throughput
    in many applications.

    An STX (02) replaces the SOH (01) at the beginning of the transmitted
    block to notify the receiver of the longer block length.  The transmitted
    block contains 1024 bytes of data.  The receiver should be able to accept
    any mixture of 128 and 1024 byte blocks.  The block number (in the second
    and third bytes of the block) is incremented by one for each block
    regardless of the block length.

    The sender must not change between 128 and 1024 byte block lengths if it
    has not received a valid ACK for the current block.  Failure to observe


    __________

     1. The name hadn't been coined yet, but the protocol was the same.

     2. See "KMD/IMP Exceptions to YMODEM" below.




    Chapter 4                                     XMODEM Protocol Enhancements







    X/YMODEM Protocol Reference    June 18 1988                             12



    this restriction allows transmission errors to pass undetected.

    If 1024 byte blocks are being used, it is possible for a file to "grow" up
    to the next multiple of 1024 bytes.  This does not waste disk space if the
    allocation granularity is 1k or greater.  With YMODEM batch transmission,
    the optional file length transmitted in the file name block allows the
    receiver to discard the padding, preserving the exact file length and
    contents.

    1024 byte blocks may be used with batch file transmission or with single
    file transmission.  CRC-16 should be used with the k option to preserve
    data integrity over phone lines.  If a program wishes to enforce this
    recommendation, it should cancel the transfer, then issue an informative
    diagnostic message if the receiver requests checksum instead of CRC-16.

    Under no circumstances may a sending program use CRC-16 unless the
    receiver commands CRC-16.

             Figure 1.  XMODEM-1k Blocks

             SENDER                                  RECEIVER
                                                     "sx -k foo.bar"
             "foo.bar open x.x minutes"
                                                     C
             STX 01 FE Data[1024] CRC CRC
                                                     ACK
             STX 02 FD Data[1024] CRC CRC
                                                     ACK
             STX 03 FC Data[1000] CPMEOF[24] CRC CRC
                                                     ACK
             EOT
                                                     ACK

             Figure 2.  Mixed 1024 and 128 byte Blocks

             SENDER                                  RECEIVER
                                                     "sx -k foo.bar"
             "foo.bar open x.x minutes"