rfc264.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 508 行 · 第 1/2 页

  |<-8-bit-> |<--24-bit-->|<8-bit><--16-bit-->|<8-bit>|<---8-bit---->|
  |<--------------------72-bit descriptor field--------------------->|

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

         _Sequence #_ is a sequential count in round-robin manner of B2,
         BA, and B4 type transactions.  The inclusion of sequence
         numbers will 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, all 1's, and zero for the
         first transaction only.

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




Bhushan, et. al.                                                [Page 5]

RFC 264                The Data Transfer Protocol       15 November 1971


         The NUL bytes must contain all 0's.

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

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

         The modes are indicated by bit-coding, as shown above.  The
         particular bits, if set to logical "1", indicate that the
         corresponding modes are handled by the sender's receive side.
         The two most significant bits should be set to logical "0".
         Mode available transactions have no significance in a simplex
         connection.  The use of type B3 transactions is discussed in
         section 3B.

   2B.5  Type B4 (information separator) transactions have a fixed
         length of four bytes, as shown below.  First byte defines the
         transaction type B4, second byte defines the separator, and
         third and fourth bytes contain a 16-bit sequence number.

         +------------+------------+-------------------------+
         |Type        |  End Code  |      Sequence Number    |
         |     B4     |            |            |            |
         |            |            |            |            |
         +------------+------------+------------+------------+

         The following separator codes are assigned:

               Code                      Meaning
         Hex             Octal

         01              001             Unit separator
         02              002             Record separator
         03              003             Group separator
         04              004             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.




Bhushan, et. al.                                                [Page 6]

RFC 264                The Data Transfer Protocol       15 November 1971


         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 four
         bytes, as shown below.  First byte defines the transaction type
         B5, second byte indicates an error code, and third and fourth
         bytes may indicate the sequence number of a transaction in
         which an error occurred.

         +------------+------------+-------------------------+
         |Type        |  End Code  |      Sequence Number    |
         |     B5     |            |            |            |
         |            |            |            |            |
         +------------+------------+------------+------------+

         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 DLF sequence (other than DLE
                                   DLE or DLE FTX).
         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 two bytes,
         as shown below.  First byte defines the transaction type B6,
         and second byte defines the abort function.

         +------------+------------+
         |Type        |  Function  |
         |     B6     |            |
         |            |            |
         +------------+------------+



Bhushan, et. al.                                                [Page 7]

RFC 264                The Data Transfer Protocol       15 November 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
         03              003             Abort preceding group
         04              004             Abort preceding file

         DTP does not require the receiver of an abort to take specific
         action, therefore a sender should not make any assumptions
         thereof.  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 (8-bit) long, and
         indicate no operation.  These may be useful as fillers when the
         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. [3]

   3B.   The first transaction after a full-duplex connection is made
         will be type B3 (modes available) indicating the transfer modes
         available for receive.  The modes available (Type B3)
         transaction is not applicable in simplex connections.  It is
         the sender's responsibility to choose a mode acceptable to the
         receiver. [4]  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.













Bhushan, et. al.                                                [Page 8]

RFC 264                The Data Transfer Protocol       15 November 1971


Endnotes

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

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

   [3]  It is, however, recommended that the standard Initial Connection
   Protocol as specified in RFC 165 or any subsequent standard document
   be adopted where feasible.

   [4]  It is suggested that when available, the sender should choose
   'descriptor and count' mode (Type B2 or BA).  The 'indefinite
   bitstream' mode (Type B0 or B8) should be chosen only when the other
   two modes are not available.









         [ This RFC was put into machine readable form for entry ]
            [ into the online RFC archives by Ryan Kato 6/01 ]























Bhushan, et. al.                                                [Page 9]