summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc281.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc281.txt')
-rw-r--r--doc/rfc/rfc281.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc281.txt b/doc/rfc/rfc281.txt
new file mode 100644
index 0000000..fad03de
--- /dev/null
+++ b/doc/rfc/rfc281.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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 which do not use
+ sequence numbering from the type of recovery under discussion; we
+ believe, however, that our suggestion eliminates at least some of
+ this problem.
+
+ Imagine that some site, which we will call the "user site" or "user",
+ has initiated a connection from its own file transfer process to a
+ file transfer process at some other site, which we will call the
+ "server site" or "server". After the appropriate exchanges of
+ information, a file transfer (using the File Transfer Protocol)
+ begins over the path between these two sites. After some information
+ is transferred, the path between the user and server is broken. At
+ some later time the user initiates a new connection between the file
+ transfer processes at user and server, establishes relevant access
+ privileges, and wishes to resume the transmission which was in
+ progress when the path was broken. First we describe four new op-
+ codes for the File Transfer Protocol:
+
+ Hex Operation
+ --- ---------
+ 10 Append at sequence number
+
+ This command is essentially the same as any of the "Store"
+ or "Append..." commands except that a 16-bit sequence
+ number immediately follows the op-code (before the
+ pathname).
+
+ 11 Retrieve at sequence number
+
+ This is the same as the "Retrieve"command except that a
+ 16-bit sequence number immediately follows the op-code
+ (before the pathname).
+
+ 12 Resume Retrieve
+
+ To be used when the user wishes the server to choose the
+ sequence number; in other respects this is identical to
+ the "Retrieve" command.
+
+
+
+
+
+
+
+
+McKenzie [Page 3]
+
+RFC 281 A Suggested Addition to File Transfer ProtocolDecember 1971
+
+
+ 13 Use the sequence number
+
+ This command contains only the op-code and a 16-bit
+ sequence number. It is intended as a denial of the
+ ability to locate the sequence number given in an "Append
+ at sequence number" or "Retrieve at sequence number"
+ command and, simultaneously, to suggest another number
+ which can be located.
+
+ There are several possible cases which are shown below. The user
+ site is always presumed to be the site at the left of the page.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McKenzie [Page 4]
+
+RFC 281 A Suggested Addition to File Transfer ProtocolDecember 1971
+
+
+ A. User site sending at time path is broken:
+ /
+ / Append at sequence number
+ | ------------------------------------------->
+ | Acknowledge
+ | <------------------------------------------
+ | Data
+ | ------------------------------------------->
+ |
+ \ The server site agrees to resume at the user-chosen point.
+ \ The first data transaction is numbered with the chosen
+ \ sequence number.
+
+ / Append at sequence number
+ / ------------------------------------------->
+ | Unsuccessful Terminate
+ | <-------------------------------------------
+ |
+ \ The server site will never permit restart for some reason
+ \ (seq. #s were ignored or not used initially, seq #s were not
+ \ stored with the file, the file was lost when the path was
+ \broken, etc.)
+
+ / Append at sequence number
+ / ------------------------------------------->
+ | Use this sequence number
+ | <-------------------------------------------
+ | / Data
+ | / --------------------------------->
+ | \ The user site agrees to use the server-chosen number
+ | \ and the first data transaction is numbered with the
+ | \ chosen number.
+ |
+ | or
+ |
+ | / Unsuccessful Terminate
+ \ / ------------------------------->
+ \ \ The user site cannot restart at this number for
+ \ \ some reason.
+
+
+
+
+
+
+
+
+
+
+
+
+McKenzie [Page 5]
+
+RFC 281 A Suggested Addition to File Transfer ProtocolDecember 1971
+
+
+ B. User site receiving at time path is broken, and the user site
+ does not particularly care about the exact sequence number (for
+ example, if the user site is sending the file to a printer, some
+ duplicate pages are probably acceptable and the user site would
+ probably not want to remember sequence numbers).
+
+ / Resume Retrieve
+ / ------------------------------------>
+ | Data
+ | <------------------------------------
+ | The server picks some point and begins transmission at
+ | that point. If sequence numbers were used during the
+ | original transmission, then the first transaction of
+ | this transmission must exactly match (including
+ | sequence number) some transaction of the original
+ \ transmission.
+
+ / Resume Retrieve
+ / ------------------------------------>
+ | Unsuccessful Terminate
+ \ <------------------------------------
+ \ The server site is unable or unwilling to restart the
+ \ transmission.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McKenzie [Page 6]
+
+RFC 281 A Suggested Addition to File Transfer ProtocolDecember 1971
+
+
+ C. User site receiving at time path is broken, and does care about
+ the value of the sequence number.
+
+ / Retrieve at sequence number
+ / ---------------------------------------->
+ | Data
+ | <----------------------------------------
+ \ The server agrees to resume at the user-chosen
+ \ point. The first data transaction is numbered
+ \ with the chosen sequence number.
+
+ / Retrieve at sequence number
+ / ---------------------------------------->
+ | Unsuccessful Terminate
+ | <----------------------------------------
+ |
+ | The server site will never permit restart for some
+ | reason.
+ | Retrieve at sequence number
+ | ---------------------------------------->
+ | Use this sequence number
+ | <-----------------------------------------
+ | / Acknowledge
+ | / ---------------------------->
+ | | Data
+ | | <----------------------------
+ | \ The user site agrees to use the
+ | \ server-chosen number. The first data
+ | \ transaction is numbered with the chosen
+ | \ number.
+ |
+ | or
+ |
+ | / Unsuccessful Terminate
+ | / ----------------------------->
+ | |
+ \ \ The server cannot use the user-chosen
+ \ \ number and the user cannot use the
+ \ \ server-chosen number. Therefore the attempt
+ \ \ to restart must be abandoned.
+
+
+
+
+
+
+
+
+
+
+
+McKenzie [Page 7]
+
+RFC 281 A Suggested Addition to File Transfer ProtocolDecember 1971
+
+
+ Some sites (e.g., UCLA-CCN) have agreed (in principle, at least) to
+ implement these commands and, more important, to store sequence
+ numbers (with files being transferred) on a non-volatile storage
+ medium so that restarts may be effected. This will be done, of
+ course, only if this, or some similar, proposal is accepted by the
+ NWG as part of the File Transfer Protocol. We hope interested
+ parties will communicate comments or counter-proposals to the FTP
+ committee and/or publish their ideas in the RFC series.
+
+ AAM/jm
+
+
+
+
+
+
+
+
+
+
+
+ [This RFC was put into machine readable form for entry]
+ [into the online RFC archives by Kelly Tardif, Viaginie 10/99]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McKenzie [Page 8]
+