RFC 281 (rfc281) - Page 1 of 8

Suggested addition to File Transfer Protocol

Alternative Format: Original Text Document
Next >
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
Next >