Browse Prior Art Database

Suggested addition to File Transfer Protocol (RFC0281)

IP.com Disclosure Number: IPCOM000003408D
Original Publication Date: 1971-Dec-08
Included in the Prior Art Database: 2000-Sep-13
Document File: 4 page(s) / 11K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A.M. McKenzie: AUTHOR

Abstract

On November 16, an informal meeting was held at UCLA to discuss prospects for a network standard Remote Job Service (RJS) protocol. In attendance were representatives of UCLA-CCN and UCSB, the network's only current RJS sites, as well as UCLA-NMC and the BBN network project. A report on that discussion will be published as an RFC shortly and will not be discussed here. In thinking about the use of the proposed File Transfer Protocol (FTP) (RFC #265) for RJS, however, we came to the conclusion that a "restart" procedure might be an extremely useful addition to the FTP.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 25% of the total text.

Network Working Group A. McKenzie

Request for Comment: 281 BBN

NIC: 8163 8 December 1971

Category: D.7

Reference: RFC #264, #265

A suggested Addition to File Transfer Protocol

On November 16, an informal meeting was held at UCLA to discuss

prospects for a network standard Remote Job Service (RJS) protocol. In

attendance were representatives of UCLA-CCN and UCSB, the

network's only current RJS sites, as well as UCLA-NMC and the BBN

network project. A report on that discussion will be published as an

RFC shortly and will not be discussed here. In thinking about the use

of the proposed File Transfer Protocol (FTP) (RFC #265) for RJS,

however, we came to the conclusion that a "restart" procedure might be

an extremely useful addition to the FTP.

Many, perhaps most, of the individuals involved in protocol design thus

far are oriented toward the use of short date transmissions over the

network the transmission lengths that have been considered "typical" are

a few characters, a print line, or perhaps as much as a page of text.

The experience of the current RJS sites, however, is that single files

are commonly much longer, for example a line-printer output file of 400

pages would not seem unusual to these sites. Further, one might

reasonably predict that network use of Remote Job Services will be

preselected with a tendency toward large jobs (although large jobs do

not necessarily imply large I/O files) and that the addition of other

batch service sites (ILLIAC, UCSD) will increase the number of long-file

transfers. In light of this kind of experience/prediction, it would

seem that the FTP should include (perhaps as an option which

interactive-user oriented systems could ignore) a method of "restarting"

a long file transfer if some element in the transmission path fails

after a large volume of data has been transferred.

The critical element in a "restart" procedure is the ability to arrange

agreement between both ends of the transmission path as to where,

exactly, the retransmission should begin. There are two potential

candidates for marking possible restart locations already built into the

proposed Data Transfer Protocol (RFC #264) which underlies the FTP;

these are:

a) The "information separators" (transaction type B4) which are

available in both "transparent block" transfers and "descriptor

and counts" transfers, and

b) The "sequence numbers" which can be used with the "descriptor

and counts" transfer mode.

After some discussion, we seemed to agree that the "information

separat...