rfc171.txt

RFC 的详细文档！

         count field.

         The NUL bytes contain all 0's.

   2B.4  Type B3 (modes available) transactions have a fixed length of 3
         bytes, as shown below.  First byte defines transaction type as
         B3, second byte defines modes available for send, and third
         byte defines modes available for receive.

         +------------------+---------------------+---------------------+
         |    Type          |     I send          |     I receive       |
         |                  | | |  |  |  |  |  |  | | |  |  |  |  |  |  |
         |     B3           |0|0|BA|B2|B9|B1|B8|B0|0|0|BA|B2|B9|B1|B8|B0|
         +------------------+---------------------+---------------------+

         The modes are indicated by bit-coding, as shown above.  The
         particular bit or bits, if set to logical "1", indicate that
         mode to be available.  The 2 most significant bits should be
         set to logical "0".  The use of type B3 transactions is
         discussed in section 3B.

   2B.5  Type B4 (information separator) transactions have fixed length
         of 2 bytes, as shown below.  First byte defines transaction
         type as B4, and second byte defines the separator.



Bhushan, et al.                                                 [Page 5]

RFC 171                THE DATA TRANSFER PROTOCOL              June 1971


         +------------------+------------------+
         |    Type          |     End Code     |
         |                  |            | |R| |
         |                  |            |G|E| |
         |     B4           |           F|R|C|U|
         |                  |           I|O|O|N|
         |                  |           L|U|R|I|
         |                  |           E|P|D|T|
         +------------------+------------------+

         The following separator codes are assigned:

                    Code                    Meaning
            Hex             Octal

            01              001             Unit separator
            03              003             Record separator
            07              007             Group separator
            0F              017             File separator

         Files, groups, records, and units may be data blocks that a
         user defines to be so.  The only restriction is that of the
         hierarchical relationship  File>Groups>Records>Units  (where
         '>' means 'contains').  Thus a file separator marks not only
         the end of file, but also the end of group, record, and unit.
         These separators may provide a convenient "logical" separation
         of data at the data transfer level.  Their use is governed by
         the applications protocol.

   2B.6  Type B5 (error codes) transactions have a fixed length of 3
         bytes, as shown below.  First byte defines transaction type as
         B5, second byte indicates an error code, and third byte may
         indicate the sequence number on which error occurred.

         +------------------+-------------------+-----------------+
         |    Type          |     Error Code    |     Sequence #  |
         |                  |                   |                 |
         |     B5           |                   |                 |
         +------------------+-------------------+-----------------+












Bhushan, et al.                                                 [Page 6]

RFC 171                THE DATA TRANSFER PROTOCOL              June 1971


         The following error codes are assigned:

             Error Code            Meaning
         Hex           Octal

         00            000         Undefined error
         01            001         Out of sync. (type code other
                                   than B0 through BF).
         02            002         Broken sequence (the sequence #
                                   field contains the first expected
                                   but not received sequence number).
         03            003         Illegal DLE sequence (other than
                                   DLE DLE or DLE ETX).
         B0            260
      through       through        The transaction type (indicated by
         BF            277         by error code) is not implemented.

         The error code transaction is defined only for the purpose of
         error control.  DTP does not require the receiver of an error
         code to take any recovery action.  The receiver may discard the
         error code transaction.  In addition, DTP does not require that
         sequence numbers be remembered or transmitted.

   2B.7  Type B6 (abort) transactions have a fixed length of 2 bytes, as
         shown below.  First byte defines transaction type as B6, and
         second byte defines the abort function.

         +-------------------+--------------------+
         |    Type           |    Function        |
         |                   |            | | |R| |
         |                   |            | |G|E| |
         |                   |            |F|R|C|U|
         |                   |            |I|O|O|N|
         |                   |            |L|U|R|I|
         |                   |            |E|P|D|T|
         +-------------------+--------------------+















Bhushan, et al.                                                 [Page 7]

RFC 171                THE DATA TRANSFER PROTOCOL              June 1971


         The following abort codes are assigned:

              Abort Code                              Meaning
            Hex            Octal

            00             000              Abort preceding transaction
            01             001              Abort preceding unit
            02             002              Abort preceding record
            07             007              Abort preceding group
            0F             017              Abort preceding file

         DTP does not require the receiver of an abort to take specific
         action, therefore sender should not necessarily make any
         assumptions.  The manner in which abort is handled is to be
         specified by higher-level applications protocols.

   2B.8  Type B7 (NoOp) transactions are one byte long, and indicate no
         operation.  These may be useful as fillers when byte size used
         for network connections is other than 8-bits.

3.  Initial Connection, Handshake and Error Recovery

   3A.  DTP does not specify the mechanism used in establishing
        connections.  It is up to the applications protocol (e.g., file
        transfer protocol) to choose the mechanism which suits its
        requirements. [6]

   3B.  The first transaction after connection is made will be type B3
        (modes available).  In a full-duplex connection, both server and
        user will communicate type B3 transactions, indicating modes
        available for send and receive.  In a simplex connection only
        sender will communicate a type B3 transaction.  It is the
        sender's responsibility to choose a mode acceptable to the
        receiver.  If an acceptable mode is not available or if mode
        chosen is not acceptable, the connection may be closed. [7]

   3C. No error recovery mechanisms are specified by DTP.  The
        applications protocol may implement error recovery and further
        error control mechanisms.

END NOTES

[1]  The term transaction is used here to mean a block of data defined
      by the transfer mode.

[2]  What constitutes a workable subset is entirely governed by the
      high-level application protocol.




Bhushan, et al.                                                 [Page 8]

RFC 171                THE DATA TRANSFER PROTOCOL              June 1971


[3]  Transactions suppress the notion of host-IMP messages, and may have
      a logical interpretation similar to that of flags (and data)
      defined by Mealy in RFC 91.

[4]  This assignment is made to be consistent with the TELNET philosophy
      of maintaining the integrity of the 128 Network ASCII characters.

[5]  A 72-b9t descriptor field provides a convenient separation of
      information bits, as 72 is the least common multiple of 8 and 36,
      the commonly encountered byte sizes on ARPA network host
      computers.

[6]  It is, however, recommended that the standard initial connection
      protocol be adopted where feasible.

[7]  It is recommended that when more than one mode is available, the
      sender should choose 'descriptor and count' mode (Type B2 or BA).
      The 'bitstream' mode (type B0 or B8) should be chosen only when
      the other two modes cannot be used.

          [ This RFC was put into machine readable form for entry ]
            [ into the online RFC archives by Samuel Etler 08/99 ]





























Bhushan, et al.                                                 [Page 9]