Another Look at Data and File Transfer Protocols
RFC - Unknown
(April 1972; No errata)
||RFC Editor Note
RFC 310 (Unknown)
||Send notices to
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
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
TIP Capabilities and TIP Users
It appears now that TIPs will not support DTP in its present form.
Show full document text