rfc171.txt

RFC技术文档 从0000－05

     three fields, a 9-byte (72-bits)(*)descriptor field and variable
     length (including zero) info and filler fields, as shown below.
     The total length of a transaction is (72+info+filler) bits.

|<B2 or BA><Info count><NUL><Seq #><NUL><filler count>|<info><filler> |
|  3-bits    24-bits 8-bits 16-bits 8-bits   8-bits   |Variable length|
|<----- 72-bit descriptor field --------------------->|info and filler|

     Info count is a binary count of number of bits in info field, not
     including descriptor or filler bits.  Number of info bits is
     limited to (2**24 - 1), as there are 24 bits in info count field.



   _________________________
   (*)
      This assignment was made to be consistent with the TELNET
   philosophy of maintaining the integrity of the 128 Network ASCII
   characters.
   (*)
      A 72-bit 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.









NWG/RFC 171                        6


     Sequence # is a sequential count in round-robin manner of B2 and BA
     type transaction.  The inclusion of sequence numbers would help in
     debugging and error control, as sequence numbers may be used to
     check for missing transactions, and aid in locating errors.  Hosts
     not wishing to implement this mechanism should have all 1's in the
     field.  The count shall start from zero and continue sequentially
     to all 1's, after which it is reset to all zeros.  The permitted
     sequence numbers are one greater than the previous, and all 1's.

     Filler count is a binary count of bits used as fillers (i.e., not
     information) after the end of meaningful data.  Number of filler
     bits is limited to 255, as there are 8 bits in filler 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          |     1 send          |     1 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.






















NWG/RFC 171                        7


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

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


















NWG/RFC 171                        8


   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| |
     |     B6            |            |F|R|C|U|
     |                   |            |I|O|O|N|
     |                   |            |L|U|R|I|
     |                   |            |E|P|D|T|
     ------------------------------------------

     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










NWG/RFC 171                        9


     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 higer-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. (*)

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.

3C. No error recovery mechanisms are specified by DTP.  The applications
    protocol may implement error recovery and further error control
    mechanisms.
   _________________________
   (*)
      It is, however, recommended that the standard initial connection
   protocol be adopted where feasible.
   (*)
     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 8/99 ]