rfc171.txt

RFC技术文档 从0000－05

Network Working Group                           23 June 1971
Request for Comments: 171                       Abhay Bhushan, MIT
NIC 6793                                        Bob Braden, UCLA
Categories: D.4, D.5, and D.7                   Will Crowther, BBN
Updates: 114                                    Eric Harslem, Rand
Obsolete: None                                  John Heafner, Rand
                                                Alex McKenzie, BBN
                                                John Melvin, SRI
                                                Bob Sundberg, Harvard
                                                Dick Watson, SRI
                                                Jim White, UCSB












                    THE DATA TRANSFER PROTOCOL

































NWG/RFC 171                        2


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, expecially 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 would provide flexibility in
   implementation, and reduce complexity.  Separating the data
   transfer function would also reduce proliferation of programs and
   protocols.
        We have therefore defined a low-level data transfer protocol
   (DTP) to be used for transfer of data in file transfer, remote
   job entry, and other applications protocols.  This paper concerns
   itself solely with the data transfer protocol.  A companion paper
   (RFC 172) describes 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.
        Three modes of separating messages into transactions(*)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).  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
   "transparent" block does not begin with DLE STX, but with a
   transaction type byte.  This mode will be useful in data transfer
   between terminal IMPs.
   _________________________
   (*)
      The term transaction is used here to mean a block of data
   defined by the transfer mode.









NWG/RFC 171                        3


        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 bits.  If a
   transaction has no filler bits, its filler count is zero.  This
   mode will be useful in most host-to-host data transfer
   applications.
        DTP allows for the above modes to be intermixed over the
   same connection (i.e., mode is not associated with connection,
   but only with transaction).  The above 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 workable(*)subset of the above modes
   is specifically permitted by DTP.  To provide compatability
   between hosts using different subsets of transfer modes, an
   initial "handshake" procedure is required by DTP.  The handshake
   involves exchanging information on modes available for transmit
   and receive.  This will enable host programs to agree on transfer
   modes acceptable for a connection.
        The manner in which DTP is used would depend largely on the
   applications protocol.  It is the applications protocol which
   defines the workable subset of transfer modes.  For example, the
   file transfer protocol will not work just with the indefinite bit
   stream modes.  At least, for control information one of the other
   two modes is required.  Again, the use of information separator
   and abort functions provided in DTP (see SPECIFICATIONS) is
   defined by the applications protocol.  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 numerous 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 applications programs.  Another implementation may employ
   _________________________
   (*)
      What constitutes a workable subset is entirely governed by the
   higher level applications protocol.










NWG/RFC 171                        4


   macros or UUO's (user unimplemented 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-bit.  However, other byte sizes specified by higher-level
    applications protocols or applications programs 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 connection is
    a sequence of transactions. (*)DTP defines the rules for
    delimiting transactions.

2A. Types

    The first 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 may be referred by the hexadecimal code
    assigned to them.  The transactions 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 (endcode).
   B5         265              Error codes.
   B6         266              Abort.
   B7         267              No operation (NoOp).
   B8         270              Indefinite bit stream--control.
   B9         271              Transparent (DLE) block--control.
   _________________________
   (*)
      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.









NWG/RFC 171                        5


BA         272              Descriptor and counts--control.
BB         273              (unassigned but reserved for data transfer)
BC         274                        "         "         "
BD         275                        "         "         "
BE         276                        "         "         "
BF         277                        "         "         "

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
     closing connection in bitstream mode represents an implicit file
     separator (see section 2B.5).

2B.2 Type B1 and B0 (transparent block modes) transactions terminate
     when the byte sequence DLE ETX is encountered.  The sender shall
     replace any occurence 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). (*)ETX is Hex '03' or Octal '03' (the same as ASCII
     ETX).

2B.3 Type B2 and BA (descriptor and counts modes) transactions have