ymodem.doc

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

    X/YMODEM Protocol Reference      08-03-87                               13



            + File names are forced to lower case unless the sending system
              supports upper/lower case file names.  This is a convenience for
              users of systems (such as Unix) which store filenames in upper
              and lower case.

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

            + When transmitting files between different operating systems,
              file names must be acceptable to both the sender and receiving
              operating systems.

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

    Length The file length and each of the succeeding fields are optional.[3]
         The length field is stored in the block as a decimal string counting
         the number of data bytes in the file.  The file length does not
         include any CPMEOF (^Z) or other garbage characters used to pad the
         last block.

         If the file being transmitted is growing during transmission, the
         length field should be set to at least the final expected file
         length, or not sent.

         The receiver stores the specified number of characters, discarding
         any padding added by the sender to fill up the last block.

    Modification Date The mod date is optional, and the filename and length
         may be sent without requiring the mod date to be sent.

         Iff the modification date is sent, a single space separates the
         modification date from the file length.

         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.





    __________

     3. Fields may not be skipped.




    Chapter 5                                     XMODEM Protocol Enhancements







    X/YMODEM Protocol Reference      08-03-87                               14



    Mode Iff the file mode is sent, 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.  rb(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 Iff the serial number is sent, a single space separates the
         serial number from the file mode.  The serial number of the
         transmitting program is stored as an octal string.  Programs which do
         not have a serial number should omit this field, or set it to 0.  The
         receiver's use of this field is optional.


    Other Fields YMODEM was designed to allow additional header fields to be
         added as above without creating compatibility problems with older
         YMODEM programs.  Please contact Omen Technology if other fields are
         needed for special application requirements.

    The rest of the block is set to nulls.  This is essential to preserve
    upward compatibility.[4]

    If the filename block is received with a CRC or other error, a
    retransmission is requested.  After the filename block has been received,
    it is ACK'ed if the write open is successful.  If the file cannot be
    opened for writing, the receiver cancels the transfer with CAN characters
    as described above.

    The receiver then initiates transfer of the file contents according to the
    standard XMODEM/CRC protocol.

    After the file contents have been transmitted, the receiver again asks for
    the next pathname.

    Transmission of a null pathname terminates batch file transmission.

    Note that transmission of no files is not necessarily an error.  This is
    possible if none of the files requested of the sender could be opened for
    reading.



    __________

     4. If, perchance, this information extends beyond 128 bytes (possible
        with Unix 4.2 BSD extended file names), the block should be sent as a
        1k block as described above.




    Chapter 5                                     XMODEM Protocol Enhancements







    X/YMODEM Protocol Reference      08-03-87                               15



    The YMODEM receiver requests CRC-16 by default.

    The Unix programs sz(1) and rz(1) included in the source code file
    RZSZ.ZOO should answer other questions about YMODEM batch protocol.

              Figure 3.  YMODEM Batch Transmission Session

              SENDER                                  RECEIVER
                                                      "sb foo.*<CR>"
              "sending in batch mode etc."
                                                      C (command:rb)
              SOH 00 FF foo.c NUL[123] CRC CRC
                                                      ACK
                                                      C
              SOH 01 FE Data[128] CRC CRC
                                                      ACK
              SOH 03 FC Data[128] CRC CRC
                                                      ACK
              SOH 04 FB Data[100] CPMEOF[28] CRC CRC
                                                      ACK
              EOT
                                                      NAK
              EOT
                                                      ACK
                                                      C
              SOH 00 FF NUL[128] CRC CRC
                                                      ACK

            Figure 4.  YMODEM Batch Transmission Session-1k Blocks

            SENDER                                  RECEIVER
                                                    "sb -k foo.*<CR>"
            "sending in batch mode etc."
                                                    C (command:rb)
            SOH 00 FF foo.c NUL[123] CRC CRC
                                                    ACK
                                                    C
            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
                                                    NAK
            EOT
                                                    ACK
                                                    C
            SOH 00 FF NUL[128] CRC CRC
                                                    ACK




    Chapter 5                                     XMODEM Protocol Enhancements







    X/YMODEM Protocol Reference      08-03-87                               16



           Figure 5.  YMODEM Filename block transmitted by sz

           -rw-r--r--  6347 Jun 17 1984 20:34 bbcsched.txt

           00 0100FF62 62637363 6865642E 74787400   |...bbcsched.txt.|
           10 36333437 20333331 34373432 35313320   |6347 3314742513 |
           20 31303036 34340000 00000000 00000000   |100644..........|
           30 00000000 00000000 00000000 00000000
           40 00000000 00000000 00000000 00000000
           50 00000000 00000000 00000000 00000000
           60 00000000 00000000 00000000 00000000
           70 00000000 00000000 00000000 00000000
           80 000000CA 56

                Figure 6.  YMODEM Header Information and Features

    _____________________________________________________________
    | Program   | Length | Date | Mode | S/N | 1k-Blk | YMODEM-g |
    |___________|________|______|______|_____|________|__________|
    |Unix rz/sz | yes    | yes  | yes  | no  | yes    | sb only  |
    |___________|________|______|______|_____|________|__________|
    |VMS rb/sb  | yes    | no   | no   | no  | yes    | no       |
    |___________|________|______|______|_____|________|__________|
    |Pro-YAM    | yes    | yes  | no   | yes | yes    | yes      |
    |___________|________|______|______|_____|________|__________|
    |CP/M YAM   | no     | no   | no   | no  | yes    | no       |
    |___________|________|______|______|_____|________|__________|
    |KMD/IMP    | ?      | no   | no   | no  | yes    | no       |
    |___________|________|______|______|_____|________|__________|

    5.1  KMD/IMP Exceptions to YMODEM

    KMD and IMP use a "CK" character sequence emitted by the receiver to
    trigger the use of 1024 byte blocks as an alternative to specifying this
    option to the sending program.  Although this two character sequence works
    well on single process micros in direct communication, timesharing systems
    and packet switched networks can separate the successive characters by
    several seconds, rendering this method unreliable.

    Sending programs may detect the CK sequence if the operating enviornment
    does not preclude reliable implementation.

    Instead of the standard YMODEM file length, KMD and IMP transmit the CP/M
    record count in the last two bytes of the header block.










    Chapter 6                                     XMODEM Protocol Enhancements







    X/YMODEM Protocol Reference      08-03-87                               17



    6.  YMODEM-g File Transmission

    Developing technology is providing phone line data transmission at ever
    higher speeds using very specialized techniques.  These high speed modems,
    as well as session protocols such as X.PC, provide high speed, nearly
    error free communications at the expense of considerably increased delay
    time.

    This delay time is moderate compared to human interactions, but it
    cripples the throughput of most error correcting protocols.

    The g option to YMODEM has proven effective under these circumstances.
    The g option is driven by the receiver, which initiates the batch transfer
    by transmitting a G instead of C.  When the sender recognizes the G, it
    bypasses the usual wait for an ACK to each transmitted block, sending
    succeeding blocks at full speed, subject to XOFF/XON or other flow control
    exerted by the medium.

    The sender expects an inital G to initiate the transmission of a
    particular file, and also expects an ACK on the EOT sent at the end of
    each file.  This synchronization allows the receiver time to open and
    close files as necessary.

    If an error is detected in a YMODEM-g transfer, the receiver aborts the
    transfer with the multiple CAN abort sequence.  The ZMODEM protocol should
    be used in applications that require both streaming throughput and error
    recovery.

            Figure 7.  YMODEM-g Transmission Session

            SENDER                                  RECEIVER
                                                    "sb foo.*<CR>"
            "sending in batch mode etc..."
                                                    G (command:rb -g)
            SOH 00 FF foo.c NUL[123] CRC CRC
                                                    G
            SOH 01 FE Data[128] CRC CRC
            STX 02 FD Data[1024] CRC CRC
            SOH 03 FC Data[128] CRC CRC
            SOH 04 FB Data[100] CPMEOF[28] CRC CRC
            EOT
                                                    ACK
                                                    G
            SOH 00 FF NUL[128] CRC CRC










    Chapter 6                                     XMODEM Protocol Enhancements







    X/YMODEM Protocol Reference      08-03-87                               18



    7.  XMODEM PROTOCOL OVERVIEW

    8/9/82 by Ward Christensen.

    I will maintain a master copy of this.  Please pass on changes or
    suggestions via CBBS/Chicago at [phone], CBBS/CPMUG [phone]
    or by voice at [phone].

    7.1  Definitions

      <soh> 01H
      <eot> 04H
      <ack> 06H
      <nak> 15H
      <can> 18H
      <C>   43H


    7.2  Transmission Medium Level Protocol

    Asynchronous, 8 data bits, no parity, one stop bit.

    The protocol imposes no restrictions on the contents of the data being
    transmitted.  No control characters are looked for in the 128-byte data
    messages.  Absolutely any kind of data may be sent - binary, ASCII, etc.
    The protocol has not formally been adopted to a 7-bit environment for the
    transmission of ASCII-only (or unpacked-hex) data , although it could be
    simply by having both ends agree to AND the protocol-dependent data with
    7F hex before validating it.  I specifically am referring to the checksum,
    and the block numbers and their ones- complement.

    Those wishing to maintain compatibility of the CP/M file structure, i.e.
    to allow modemming ASCII files to or from CP/M systems should follow this
    data format:

       + ASCII tabs used (09H); tabs set every 8.

       + Lines terminated by CR/LF (0DH 0AH)

       + End-of-file indicated by ^Z, 1AH.  (one or more)

       + Data is variable length, i.e. should be considered a continuous
         stream of data bytes, broken into 128-byte chunks purely for the
         purpose of transmission.

       + A CP/M "peculiarity": If the data ends exactly on a 128-byte
         boundary, i.e. CR in 127, and LF in 128, a subsequent sector
         containing the ^Z EOF character(s) is optional, but is preferred.
         Some utilities or user programs still do not handle EOF without ^Zs.





    Chapter 7                                         Xmodem Protocol Overview