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
