Browse Prior Art Database

Suggested addition to File Transfer Protocol (RFC0281) Disclosure Number: IPCOM000003408D
Original Publication Date: 1971-Dec-01
Included in the Prior Art Database: 2019-Feb-13
Document File: 8 page(s) / 8K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A.M. McKenzie: AUTHOR

Related Documents

10.17487/RFC0281: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 28% 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

McKenzie [Page 1]

RFC 281 A Suggested Addition to File Transfer ProtocolDecember 1971

b) The "sequence numbers" which can be used with the "descriptor and counts" transfer mode.

McKenzie [Page 2]

RFC 281 A Suggested Addition to File Transfer ProtocolDecember 1971

After some discussion, we seemed to agree that the "information separators" (as they would be used in "transparent block" transfer mode, i.e., without "sequence numbers") were unlikely to serve as UNAMBIGUOUS restart location marker, and therefore we suggest the use of "sequence numbers" as markers. We were aware of the fact that this choice might exclude TIPs and other Hosts...