NETWORK WORKING GROUP R. L. Sunberg Request for Comments #133 Harvard University
IC 6710 27 April 1971
FILE TRANSFER AND ERROR RECOVERY
[Categories C.4, C.5, C.6, D.4, D.7, D.7]
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).
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.
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:
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
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).
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 move of the given <pathname> specifiers are
listed in a return file. The format of the data fiels 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 DC1DSK[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.
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.
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.
transaction codes, this form of error recovery is implementable in
any protocol which uses flagged blocking and duplex connections.
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
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 assumed that any process can flush untransmitted data and
detect a clear link. Note that this method is useable on any
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
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 ]