ymodem.doc

计算机的modem协议,给大家做一个参考吧。

    X/YMODEM Protocol Reference      08-03-87                                7



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


    __________

     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      08-03-87                                8



    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      08-03-87                                9



    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      08-03-87                               10



    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
    per byte overhead 3 per cent on long files.

    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, but some environments cannot accept 1024 byte
    bursts, especially minicomputers running 19.2kb ports.

    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
    this restriction allows transmission errors to pass undetected.



    __________

     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      08-03-87                               11



    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
                                                      "s -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
                                                      "s -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
              SOH 03 FC Data[128] CRC CRC
                                                      ACK
              SOH 04 FB Data[100] CPMEOF[28] CRC CRC
                                                      ACK
              EOT
                                                      ACK







    Chapter 4                                     XMODEM Protocol Enhancements







    X/YMODEM Protocol Reference      08-03-87                               12



    5.  YMODEM Batch File Transmission

    The YMODEM Batch protocol is an extension to the XMODEM/CRC protocol that
    allows 0 or more files to be transmitted with a single command.  (Zero
    files may be sent if none of the requested files is accessible.) The
    design approach of the YMODEM Batch protocol is to use the normal routines
    for sending and receiving XMODEM blocks in a layered fashion similar to
    packet switching methods.

    Why was it necessary to design a new batch protocol when one already
    existed in MODEM7?[1] The batch file mode used by MODEM7 is unsuitable
    because it does not permit full pathnames, file length, file date, or
    other attribute information to be transmitted.  Such a restrictive design,
    hastily implemented with only CP/M in mind, would not have permitted
    extensions to current areas of personal computing such as Unix, DOS, and
    object oriented systems.  In addition, the MODEM7 batch file mode is
    somewhat susceptible to transmission impairments.

    As in the case of single a file transfer, the receiver initiates batch
    file transmission by sending a "C" character (for CRC-16).

    The sender opens the first file and sends block number 0 with the
    following information.[2]

    Only the pathname (file name) part is required for batch transfers.

    To maintain upwards compatibility, all unused bytes in block 0 must be set
    to null.

    Pathname The pathname (conventionally, the file name) is sent as a null
         terminated ASCII string.  This is the filename format used by the
         handle oriented MSDOS(TM) functions and C library fopen functions.
         An assembly language example follows:
                                  DB      'foo.bar',0
         No spaces are included in the pathname.  Normally only the file name
         stem (no directory prefix) is transmitted unless the sender has
         selected YAM's f option to send the full pathname.  The source drive
         (A:, B:, etc.) is not sent.

         Filename Considerations:



    __________

     1. The MODEM7 batch protocol transmitted CP/M FCB bytes f1...f8 and
        t1...t3 one character at a time.  The receiver echoed these bytes as
        received, one at a time.

     2. Only the data part of the block is described here.




    Chapter 5                                     XMODEM Protocol Enhancements