RFC 310 (rfc310) - Page 2 of 7
Another Look at Data and File Transfer Protocols
Alternative Format: Original Text Document
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