rfc310.txt

RFC技术文档 从0000－05

Network Working Group                                         A. Bhushan
Request for Comments: 310                                        MIT-MAC
NIC: 9261                                                  April 3, 1972


            Another Look At Data And File Transfer Protocols

   Our experience with ad hoc techniques of data and file transfer over
   the ARPANET together with a better knowledge of terminal IMP (TIP)
   capabilities and Datacomputer requirements has indicated to us that
   the Data Transfer Protocol (DTP) (see ref 1) and the File Transfer
   Protocol (FTP) (see ref 2) could undergo revision.  Our effort in
   implementing DTP and FTP has revealed areas in which the protocols
   could be simplified without degrading their usefulness.

   This paper suggests some specific changes in DTP and FTP that should
   make them more useful and/or simplify implementation.  The attempt
   here is to stimulate thinking so that we may come up with a better
   protocol at the forthcoming Data and File Transfer Workshop (see ref
   3).

Experience to Date

   A number of ad hoc techniques of transmitting data and files across
   the ARPANET already exist.  Perhaps, the most versatile of these
   existing methods is the TENEX "CPYNET" system.  The "CPYNET" system
   uses an ad hoc or interim file transfer protocol developed by Ray
   Tomlinson and others at BBN to transmit files among the TENEX systems
   on the ARPANET. [Private Communication with Bill Crowther, BBN.]

   In CPYNET, the using process goes through the Initial Connection
   Protocol (ICP) to server socket 7, establishing a full-duplex
   connection with an 8-bit byte size.  Control information, including
   user name, password, command (read, write, or append), file name, and
   byte size for the data connection is transmitted from the using
   process to the serving process.  The original full-duplex connection
   is then closed, and a new full-duplex connection is established using
   the original socket numbers but with possibly a different byte size.
   The file is now transmitted on this newly established connection.
   The end-of-file is indicated by closing the connection (the mode of
   transfer is thus similar to DTP "indefinite bit-stream").

   CPYNET has been used quite extensively for transfer of TENEX system
   files.  Because data is not reformatted, and because the optimum
   connection byte size may be used for data transfer, CPYNET is quite
   efficient.  The PDP-10 (and there are quite a lot in the ARPANET)
   works more efficiently with a 36 bit byte size which minimizes
   packing and unpacking of data, and increases effective I/O speed



Bhushan                                                         [Page 1]

RFC 310               Another Look At Data And FTP            April 1972


   (bit rate is 36 times the I/O word transfer rate instead of 8 times).
   The closing and reopening of connections does increase overhead but
   this is small in TENEX when compared with inefficiency introduced in
   data transfer using an inappropriate byte size.

   Data and file transfer has been achieved at other sites by a simple
   modification of the user TELNET to enable the transfer of ASCII files
   as terminal I/O data streams within the constraints of the TELNET
   protocol.  An example of this approach is the use of the "send.file"
   and "script" features within the MIT-DMCG user-TELNET.  Send.file
   enables the PDP-10 (DMCG) user to transmit his local ASCII files to a
   receiving process such as an editor at the remote host via a TELNET
   connection.  The program allows for a variable buffer size for
   transmission, and measures the transfer rate of information bits.
   Script enables a user to receive an ASCII file from a remote host by
   essentially printing it out (the terminal output stream is directed
   to a local file).

   Our initial experience with the use of send.file program has affirmed
   the almost linear relationship between buffer size and transmission
   rate (inverse relationship to processing cost) until the limits
   imposed by allocates, NCP sending buffers, the IMP message size, or
   the receiving process speed, are reached.  Our experiments have
   indicated that TELNET processes in which the receiving process
   "looks" at each character are slow and expensive.  The transfer rate
   to most TELNET receiving processes ranges between 200 and 2,000 bits
   per second.  The NCP-to-NCP transmission rate however is an order-
   of-magnitude higher (2,000 to 20,000 bits per second).

   A variation of the above method which avoids the character-by-
   character processing of TELNET, is transmitting files via auxiliary
   connections (other than the TELNET connections) with or without the
   use of DTP.  We are collecting data on response times, connect times
   and transfer speeds employing different transfer and buffering
   strategies.

TIP Capabilities and TIP Users

   It appears now that TIPs will not support DTP in its present form.
   The more elaborate TIPs with magnetic tape units will however,
   support the DTP block mode (descriptor and counts) [Private
   Communication with Bill Crowther, BBN.]  It is inconvenient, at the
   very least, for a TIP user to use services based on DTP (such as
   remote job service, file transfer, mail, and Datacomputer).  The TIP
   philosophy is that "the computational load and storage should be in
   the hosts or in the terminals and not in the terminal processor."
   (See ref 4.) To be consistent with this philosophy the protocols
   should be simple and convenient to use from the user viewpoint.



Bhushan                                                         [Page 2]

RFC 310               Another Look At Data And FTP            April 1972


   Ideally, TIP users would like to connect (using the initial
   connection protocol) to the advertised service socket (including
   logger socket1) in the remote host and type their commands in a
   uniform, easy to use, format.  Allowing the use of ASCII within DTP
   would facilitate this.  (An alternate approach is extending TELNET to
   include DTP modes, particularly the indefinite bit-stream mode.)
   Another step would be to use printable ASCII strings instead of
   numeric codes for commands and arguments in user-level protocols.
   Use of standard file system commands (with uniform interpretation and
   format) will lead towards the existence of a Network Virtual File
   System, much in the same line as Network Virtual Terminal defined in
   TELNET protocol.

   The transparent mode in DTP was specifically included to allow
   convenient use by TIPs.  Since the TIPs will not support transparent
   mode, it makes sense to do away with it.  This change would lead to a
   simplier DTP which allows transfer in Block mode, and the indefinite
   bit-stream mode.  (The suggested default which would be acceptable to
   all including the TIPs, as it involves no overhead.).  We can then
   make optional or do away with the now mandatory modes available
   handshake.  The using process can indicate if it also accepts the
   block mode for transfer.  (Either by modes available transaction, or
   by an argument in the command string).  The server should accept
   input in DTP mode as well as ASCII.  These fundamental changes in DTP
   will make communication with TIPs a lot easier.

   TIP users who do not have a mediating user-FTP process and a file
   system in their TIP, would probably want to transfer files from input
   devices or to output devices such as line printer, card reader or
   punch, or magnetic tape.  These devices "listen" on specific "ports"
   or sockets on a TIP.  It would be desirable to modify FTP to allow
   sending data to a specified socket in a specified mode and type.  TIP
   users would then find it convenient to obtain listing of their files
   on a high-speed line printer, input their files from a card reader,
   and keep back-up on cards or magnetic tapes.

Datacomputer Requirements

   We have been having a continuing dialogue with CCA personnel (Dick
   Winter in particular), regarding CCA's plans for data and file
   transfer on the Datacomputer, and their specific requirements.  Dick










Bhushan                                                         [Page 3]

RFC 310               Another Look At Data And FTP            April 1972


   Winter will be speaking on this subject at the Data and File Transfer
   Workshop.  This is an attempt to summarize the main points of our
   discussion, and their implication for data and file transfer.

   First, CCA appears quite flexible at this stage regarding the manner
   in which Datacomputer is to be used.  Even the Datalanguage (see ref
   5) is flexible and can undergo change.  However, CCA would like some
   changes in the current file transfer protocol and its envisioned use.

   Ideally, CCA would like to see a single full-duplex connection for
   transfer of all control information which is in Datalanguage.  This
   information is generated by a process, which may be a user at a
   console, or a user program.  Ability to inter-mix data and control
   information would be definite advantage.  The Datacomputer would
   probably support DTP and allow use of TELNET-ASCII.

   Data may alternatively be sent to or received from a separate user
   defined port (which may be a socket).  It would be advantageous if a
   user could instruct the Datacomputer to transfer data to or from a
   file in remote system via FTP (assuming a server-FTP in remote
   system).  CCA is currently not committed to this idea, but is
   considering it.

   In the CCA view, the Datacomputer represents a data management