rfc264.txt

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

Network Working Group                                         A. Bhushan
Request for Comments: 264                                            MIT
NIC: 7812                                                      B. Braden
                                                                    UCLA
                                                             W. Crowther
                                                                     BBN
                                                              E. Harslem
                                                              J. Heafner
                                                                    Rand
                                                             A. McKenzie
                                                                     BBN
                                                               J. Melvin
                                                                     SRI
                                                             B. Sundberg
                                                                 Harvard
                                                               D. Watson
                                                                     SRI
                                                                J. White
                                                                    UCSB
                                                        15 November 1971


                       THE DATA TRANSFER PROTOCOL

   This paper is a revision of RFC 171, NIC 6793.  The changes to RFC
   171 are given below.  The protocol is then restated for your
   convenience.

CHANGES TO RFC 171

   1) The sequence number field is changed to 16 bits in the error (Type
      B5) transactions, thus resolving the ambiguity in the previous
      specification.  In addition, the information separators (Type B4)
      transactions shall also contain a 16-bit sequence number field.

   2) The modes available (Type B3) transactions shall define only the
      modes available for receive, instead of both receive and send.  In
      simplex connections modes available transactions should not be
      sent as they are meaningless.  In full-duplex connections, the
      modes available transactions are still required.

   3) The code assignments for "End Code" in information separators and
      for "function" in abort transactions have been changed to reflect
      a numerical order rather than "bit-coding".

   4) Minor editorial changes.





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


I.  INTRODUCTION

      A common protocol is desirable for data transfer in such diverse
      applications as remote job entry, file transfer, network mail
      system, graphics, remote program execution, and communication with
      block data terminals (such as printers, card, paper tape, and
      magnetic tape equipment, especially in context of terminal IMPs).
      Although it would be possible to include some or even all of the
      above applications in an all-inclusive file transfer protocol, a
      separation between data transfer and application functions may
      provide flexibility in implementation, and reduce complexity.
      Separating the data transfer function from the specific
      applications functions may also reduce proliferation of programs
      and protocols.

      We have therefore defined a data transfer protocol (DTP) which
      should be used for transfer of data in file transfer, remote job
      entry, and other applications protocols.  This paper concerns
      itself only with the data transfer protocol.  A companion paper
      (RFC 265) describes the file transfer protocol.

II.  DISCUSSION

      The data transfer protocol (DTP) serves three basic functions.  It
      provides for convenient separation of NCP messages into "logical"
      blocks (transactions, units, records, groups, and files), it
      allows for the separation of data and control information, and it
      includes some error control mechanisms.

Transfer Modes

      Three modes of separating messages into transactions [1] are
      allowed by DTP.  The first is an indefinite bit stream which
      terminates only when the connection is closed (i.e., the bit
      stream represents a single transaction for duration of
      connection).  This mode would be useful in data transfer between
      hosts and terminal IMPs (TIPs).

      The second mode utilizes a "transparent" block convention, similar
      to the ASCII DLE (Data Link Escape) convention.  In "transparent"
      mode, transactions (which may be arbitrarily long) end whenever
      the character sequence DLE ETX is encountered (DLE and ETX are 8-
      bit character codes).  To prevent the possibility of a DLE ETX
      sequence occurring within data stream, any occurrence of DLE is
      replaced by DLE DLE on transmission.  The extra DLE is stripped on
      reception.  A departure from the ASCII convention is that





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


      "transparent" block does not begin with DLE STX, but with a
      transaction type byte.  This mode would be useful in data transfer
      between terminal IMPs.

      The third mode utilizes a count mechanism.  Each transaction
      begins with a fixed-length descriptor field containing separate
      binary counts of information bits and filler (i.e., not
      information) bits.  If a transaction has no filler bits, its
      filler count is zero.  This mode would be useful in most host-to-
      host data transfer applications.

      DTP allows for transfer modes to be intermixed over the same
      connection (i.e., the transfer mode is not associated with
      connection, but only with transaction).  The transfer modes can
      represent transfer of either data or control information.  The
      protocol allows for separating data and control information at a
      lower level, by providing different "type" codes (see
      SPECIFICATIONS) for data and control transactions.  This provision
      may simplify some implementations.

      The implementation of a subset of transfer modes is specifically
      permitted by DTP.  To provide compatibility between hosts using
      different subsets of transfer modes, an initial "handshake"
      procedure may be used.  The handshake involves exchanging
      information on modes available for receive.  This will enable host
      programs to agree on transfer modes acceptable for a connection.

Using DTP

      The manner in which DTP is used would depend largely on the
      applications protocol.  It is the applications protocol which
      defines the use of transfer modes and the use of information
      separator and abort functions provided in DTP (see
      SPECIFICATIONS).  For example, in a remote job entry protocol,
      aborts may be used to stop the execution of a job, while they may
      not cause any action in another applications protocol.

      It should also be noted that DTP does not define a data transfer
      service.  There is no standard server socket, or initial
      connection protocol defined for DTP.  What DTP defines is a
      mechanism for data transfer which can be used to provide services
      for block data transfers, file transfers, remote job entry,
      network mail and other applications.

      There are to be no restrictions on the manner in which DTP is
      implemented at various sites.  For example, DTP may be imbedded in
      an applications program such as for file transfer, or it may be a
      separate service program or subroutine used by several



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


      applications programs.  Another implementation may employ macros
      or UUO's (unimplemented user operations on PDP-10's), to achieve
      the functions specified in DTP.  It is also possible that in
      implementation, the separation between the DTP and applications
      protocols be only at a conceptual level.

III.  SPECIFICATIONS

   1.    Byte Size for Network Connection

         The standard byte size for network connections using DTP is 8
         bits.  However, other byte sizes specified by applications
         protocols are also allowed by DTP.  For the purpose of this
         document bytes are assumed to be 8-bits, unless otherwise
         stated.

   2.    Transactions

         At DTP level, all information transmitted over a connection is
         a sequence of transactions.  DTP defines the rules for
         delimiting transactions.

   2A.   Types

         The first 8-bit byte of each transaction shall define a
         transaction type, as shown below.  (Note that code assignments
         do not conflict with assignments in TELNET protocol.)  The
         transaction types will be referred to by the hexadecimal code
         assigned to them.  (The transaction types are discussed in more
         detail in Section 2B.)

            Code                    Transaction Type
         Hex     Octal

         B0      260             Indefinite bit stream -- data.
         B1      261             Transparent (DLE) block--data.
         B2      262             Descriptor and counts--data.
         B3      263             Modes available (handshake).
         B4      264             Information Separators.
         B5      265             Error codes.
         B6      266             Abort.
         B7      267             No operation (NoOp).
         B8      270             Indefinite bit stream--control.
         B9      271             Transparent (DLE) block--control.
         BA      272             Descriptor and counts--control.
         BB      273
         through through         Unassigned but reserved for DTP.
         BF      277



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


   2B.  Syntax and Semantics

   2B.1  Type B0 and B8 (indefinite bitstream modes) transactions
         terminate only when the NCP connection is "closed".  There is
         no other escape convention defined in DTP at this level.  It
         should be noted that the closing of a connection in bitstream
         mode is an implicit file separator (see Section 2B.5).

   2B.2  Type B1 and B9 (transparent block modes) transactions terminate
         when the byte sequence DLE ETX is encountered.  The sender
         shall replace any occurrence of DLE in data stream by the
         sequence DLE DLE.  The receiver shall strip the extra DLE.  The
         transaction is assumed to be byte-oriented.  The code for DLE
         is Hex '90' or Octal '220' (this is different from the ASCII
         DLE which is Hex '10' or Octal '020).  [2] ETX is Hex '03' or
         Octal '03' (the same as ASCII ETX).

   2B.3  Type B2 and BA (descriptor and counts modes) transactions have
         three fields, a 9-byte (72-bit) descriptor field (as shown
         below) and variable length (including zero) info and filler
         fields.  The total length of a transaction is (72+info+filler)
         bits.

  |<B2 or BA>|<Info count>| <NUL> <Sequence #>| <NUL> |<filler count>|