File Transfer and Error Recovery
A 1971 critique of the early file transfer proposal: answer every message, recover from errors in levels, and number the NCP.
Sunberg, R.L., "File Transfer and Error Recovery", RFC 133, DOI 10.17487/RFC0133, April 1971, <https://www.rfc-editor.org/info/rfc133>.
@misc{rfc133,
series = {Request for Comments},
number = 133,
howpublished = {RFC 133},
publisher = {RFC Editor},
doi = {10.17487/RFC0133},
url = {https://www.rfc-editor.org/info/rfc133},
author = {R.L. Sunberg},
title = {{File Transfer and Error Recovery}},
pagetotal = 4,
year = 1971,
month = apr,
} RFC text
Contents
Network Working Group R. L. Sunberg
Request for Comments: 133 Harvard University
NIC 6710 27 April 1971
[Categories C.4, C.5, C.6, D.4, D.7, D.7]
FILE TRANSFER AND ERROR RECOVERY
1 FILE TRANSFER PROTOCOL
1A Handshaking
I think that Mr Bhushan(RFC #114, NIC 5823) is not strict enough in
his concept of a transaction sequence. Every transaction should
prompt a response from its recipient (recall Kalin's crates --
RFC #60, NIC 4762). Control should pass back and forth until the
server terminates. The server _always_ gets the last word (more on
error recovery later).
Some sample interchanges are given.
User Server Comments
<...> ==> Establish a connection
<== <...>
<I><...> ==> Identify self
<== <+> Ok, ready
<R><...> ==> Retrieval request
<== <rs> I've got your file
<rr> ==> Send it
<== <,><...> Here's the first part
<rr> ==> Got it
<== <+> All done
<S><...> ==> Store request
<== <rr> Ok, go ahead
<#><...> ==> Here's some protection stuff
<== <rr> Ok
<*><...> ==> Here's the file
<== <+> Got it. All done.
See section 2B, below, for examples of error recovery.
1B Extensions to the file transfer protocol
The file transfer protocol needs a mechanism for accessing individual
records of a file. This will be particularly useful when very large
data bases appear on the network. The following definitions should
be added to the protocol:
The store(S) and retrieve(R) requests have the data field format
<key>, where <key> has the syntax:
<key>::=<devicename>RS<filename>US<keyname> | <filename>US<keyname>.
-- -- --
The <pathname> syntax is changed to:
<pathname>::=<devicename> | <filename> | <pathname>RS<filename>.
--
If a retrieve(R) request is given with a data field with <key>
syntax rather than <pathname> syntax, then the returned data will
consist of the record following the matching <key>. If a store(S)
request is given with a data field of <key> syntax, then the
supplied data will replace the record following the matching
<keyname>. If the keyname does not exist, the record will be
appended to the named file. The individual installation must
provide the linkage between the <keyname> and the record it
references.
In addition, the lookup(L) request will provide a list of keynames
into a file (or the name of a file which contains the keynames).
Transaction code F (request File directory) requests a listing of
available files. The data field of the F transaction is of the
form: <pathname>GS<pathname>GS... All files in the server system
-- --
which match one or more of the given <pathname> specifiers are
listed in a return file. The format of the data fields of this
file is: <pathname>GS<pathname>GS... If a <pathname> field in
-- --
the request transaction does not include a <name> field, the
default is all files on the given device. Some examples are given:
<F><DC1 DSK[62,50]] GS JOE>
--- --
This example requests a list of all files on the disk specified by
[62,50] plus all files named JOE. The response could contain in
the data field:
<DC1 DSK[62,50] RS ALPHA RS BETA RS JOE GS DC1 DSK[10,50] RS JOE>
--- -- -- -- -- --- --
This message states that in the [62,50] area of the disk there are
files ALPHA, BETA, and JOE, and that JOE is also a file in the
[10,50] area of the disk.
2 ERROR RECOVERY
2A Error recovery procedures have been noticeably lacking to date.
The usual approach has been to close the connection and start from
scratch. Mr Bhushan proposes a third level abort but doesn't
really detail the implementation. I propose a multilevel error
recovery procedure as follows.
2B If an error occurs which does not cause a loss of third level
transaction boundaries and only affects one side of a duplex
connection, a third level recovery is possible via a transaction
sequence abort. An example is given:
User Server Comments
<R><...> ==> Send me this file
<== <rs> Ok, I've got it
<rr> ==> Ready
<== <*><...error> Here it is (with an error)
<-><D> ==> No. (data) error
<== <-><D> Sorry, forget it
<R><...> ==> Send the file (again)
|<== <rs> Ready (doesn't get there)
... (waiting)
<-><0> ==> Error, timeout
<== <-><0> Sorry, forget it
<R><...> ==> Send the file (third time)
<== <rs> Got it
<rr> ==> Ready
<== <*><...> There it is
<rr> ==> Got it
<== <+> Done (finally>
Note that the server always gets the last word in error situations
as well as normal transmission.
2C Although the above examples are given in terms of Bhushan's
transaction codes, this form of error recovery is implementable in
any protocol which uses flagged blocking and duplex connections.
2D If errors cannot be recovered as above, then some means must be
available to clear the link completely and resynchronize. I
suggest that an 8-bit argument be appended to the interrupt-on-link
NCP message (INR, INS). The receiver would send <INR><error> to
indicate that the block boundaries were lost and all incoming data
is being discarded. The sender, upon receiving the INR, would
flush all queued output and wait for the link to clear. The NCP
would then send a <INS><newsync> message and, when it was received
(RFNM returned), a negative termination would be sent on the link.
The receiver begins accepting data again when the INS is received.
This assumes that any process can flush untransmitted data and
detect a clear link. Note that this method is useable on any
simplex connection.
2E If all else fails, one can resort to closing the faulty socket.
3 NCP VERSION NUMBERS
3A I suggest that the NCP be given a version number and the next
version include two new message types: <WRU> ('Who aRe yoU?')
requests a version number from the receiving host and <IAM><version>
('I AM') supplies that number.
3B The messages would probably be initially used in a 'can I talk to
you?' sense or not at all. Eventually, it would take on a 'what
can you do?' meaning. Accordingly, the <version> field should be
large (32 bits?) for expansion.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Jose Tamayo 4/97 ]
AI ELI5
On this page
§1Handshaking in File Transfer
The author thinks the file transfer proposal in RFC 114 is not strict enough about what a transaction sequence is. Every transaction should prompt a response from its recipient, and control should pass back and forth until the server ends the exchange. The server always gets the last word.
The RFC gives sample exchanges. In a retrieval, the user sends an R request, the server answers rs (I have your file), the user says rr (send it), the server sends the first part, the user acknowledges with rr, and the server closes with + (all done). A store request runs the same way in the other direction.
Every time you say something, the other side says something back, like a game of catch. The helper always makes the last throw.
- RRetrieval request.
- rsI have your file.
- rrSend it.
- ,Here is the first part.
- rrGot it.
- +All done.
§2Extensions to the Protocol
The protocol needs a way to reach individual records of a file, which would matter once very large data bases appear on the network. The store (S) and retrieve (R) requests would accept a key made of a file name and a key name. A retrieve with a key returns the record after the matching key. A store with a key replaces that record, or appends it to the file if the key name does not exist. Each installation must supply the link between a key name and its record.
A lookup (L) request would list the key names in a file. A new transaction code F requests a file directory listing: the data field holds one or more path names, and the server returns a file listing every file that matches. A path name with no file name means all files on the given device.
Instead of fetching a whole book, you could ask for one page by its label. You could also ask for a list of all the books on the shelf.
§3Multilevel Error Recovery
The author notes that error recovery has been noticeably lacking: the usual approach is to close the connection and start from scratch. The proposal is a multilevel procedure.
If an error does not lose the third level transaction boundaries and affects only one side of a duplex connection, a transaction sequence abort is enough. In the sample, a data error is answered with an abort message, the server replies that it forgets the transfer, and the user asks again. A timeout is handled the same way. The server again has the last word. This works in any protocol that uses flagged blocking and duplex connections.
If that fails, the link must be cleared and resynchronized. The author suggests an 8-bit argument on the interrupt-on-link NCP messages (INR, INS): the receiver sends INR with an error code and discards incoming data, the sender flushes its queue, and the NCP sends INS with a new sync value. If all else fails, close the faulty socket.
If a toy gets broken in the mail, first you ask for a new one. If the whole mailbox is a mess, you clear it out and begin again. Closing the mailbox is the last choice.
§4NCP Version Numbers
The author suggests giving the NCP a version number. The next version would add two message types: WRU (who are you), which asks the receiving host for its version number, and IAM, which supplies it.
At first these would mean roughly can I talk to you, and over time they would come to mean what can you do. For that reason the version field should be large, with 32 bits suggested for expansion.
Before talking, the computers could ask each other which edition of the rules they know, like checking you both have the same rulebook.