RFC 310 (rfc310) - Page 2 of 7

Another Look at Data and File Transfer Protocols

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