From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc133.txt | 227 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 doc/rfc/rfc133.txt (limited to 'doc/rfc/rfc133.txt') diff --git a/doc/rfc/rfc133.txt b/doc/rfc/rfc133.txt new file mode 100644 index 0000000..65b720b --- /dev/null +++ b/doc/rfc/rfc133.txt @@ -0,0 +1,227 @@ + + + + + + +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 + <== <...> + <...> ==> Identify self + <== <+> Ok, ready + + <...> ==> Retrieval request + <== I've got your file + ==> Send it + <== <,><...> Here's the first part + ==> Got it + <== <+> All done + + <...> ==> Store request + <== Ok, go ahead + <#><...> ==> Here's some protection stuff + <== Ok + <*><...> ==> Here's the file + <== <+> Got it. All done. + + See section 2B, below, for examples of error recovery. + + + + + + + +Sunberg [Page 1] + +RFC 133 File Transfer and Error Recovery April 1971 + + +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 + , where has the syntax: + + ::=RSUS | US. + -- -- -- + + The syntax is changed to: + + ::= | | RS. + -- + If a retrieve(R) request is given with a data field with + syntax rather than syntax, then the returned data will + consist of the record following the matching . If a store(S) + request is given with a data field of syntax, then the + supplied data will replace the record following the matching + . If the keyname does not exist, the record will be + appended to the named file. The individual installation must + provide the linkage between the 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: GSGS... All files in the server system + -- -- + which match one or more of the given specifiers are + listed in a return file. The format of the data fields of this + file is: GSGS... If a field in + -- -- + the request transaction does not include a field, the + default is all files on the given device. Some examples are given: + + + --- -- + + + + + + + + +Sunberg [Page 2] + +RFC 133 File Transfer and Error Recovery April 1971 + + + 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: + + + --- -- -- -- -- --- -- + + 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 + + <...> ==> Send me this file + <== Ok, I've got it + ==> Ready + <== <*><...error> Here it is (with an error) + <-> ==> No. (data) error + <== <-> Sorry, forget it + <...> ==> Send the file (again) + |<== Ready (doesn't get there) + ... (waiting) + <-><0> ==> Error, timeout + <== <-><0> Sorry, forget it + <...> ==> Send the file (third time) + <== Got it + ==> Ready + <== <*><...> There it is + ==> Got it + <== <+> Done (finally> + + Note that the server always gets the last word in error situations + as well as normal transmission. + + + + + +Sunberg [Page 3] + +RFC 133 File Transfer and Error Recovery April 1971 + + +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 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 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: ('Who aRe yoU?') + requests a version number from the receiving host and + ('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 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 ] + + + + + + + + + + + + + + + +Sunberg [Page 4] + -- cgit v1.2.3