home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 1 / rfc0133.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  7.8 KB  |  284 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. NETWORK WORKING GROUP                                   R. L. Sunberg
  8. Request for Comments #133                               Harvard University
  9.  IC 6710                                                 27 April 1971
  10.  
  11.                     FILE TRANSFER AND ERROR RECOVERY
  12.  
  13.     [Categories C.4, C.5, C.6, D.4, D.7, D.7]
  14. 1   FILE TRANSFER PROTOCOL
  15.  
  16. 1A  Handshaking
  17.  
  18. 1A1 I think that Mr Bhushan(RFC #114, NIC 5823) is not strict enough in
  19.  
  20.     his concept of a transaction sequence.  Every transaction should
  21.  
  22.     prompt a response from its recipient )recall Kalin's crates --
  23.  
  24.     RFC #60, NIC 4762).  Control should pass back and forth until the
  25.  
  26.     server terminates.  The server  always gets the last word (more on
  27.  
  28.     error recovery later).
  29.  
  30. 1A2 Some sample interchanges are given.
  31.  
  32.     User                Server          Comments
  33.     <...>       ==>                     Establish a connection
  34.                 <==     <...>
  35.     <I><...>    ==>                     Identify self
  36.                 <==     <+>             Ok, ready
  37.  
  38.     <R><...>    ==>                     Retrieval request
  39.                 <==     <rs>            I've got your file
  40.     <rr>        ==>                     Send it
  41.                 <==     <,><...>        Here's the first part
  42.     <rr>        ==>                     Got it
  43.                 <==     <+>             All done
  44.  
  45.     <S><...>    ==>                     Store request
  46.                 <==     <rr>            Ok, go ahead
  47.     <#><...>    ==>                     Here's some protection stuff
  48.                 <==     <rr>            Ok
  49.     <*><...>    ==>                     Here's the file
  50.                 <==     <+>             Got it.  All done.
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. NWG/RFC #133
  61.  
  62.  
  63.     See section 2B, below, for examples of error recovery.
  64.  
  65. 1B  Extensions to the file transfer protocol
  66.  
  67. 1B1 The file transfer protocol needs a mechanism for accessing
  68.  
  69.     individual records of a file.  This will be particularly useful
  70.  
  71.     when very large data bases appear on the network.  The following
  72.  
  73.     definitions should be added to the protocol:
  74.  
  75.  
  76.     The store(s) and retrieve(R) requests have the data field format
  77.  
  78.     <key>, where <key> has the syntax:
  79.  
  80.     <key>::=<devicename>RS<filename>US<keyname>|<filename>US<keyname>.
  81.  
  82.       The <pathname> syntax is changed to:
  83.  
  84.     <pathname>::=<devicename>/<filename>/<pathname>RS<filename>.
  85.  
  86.  
  87.     If a retrieve(R) request is given with a data field with <key>
  88.  
  89.     syntax rather than <pathname> syntax, then the returned data will
  90.  
  91.     consist of the record following the matching <key>.  If a store(s)
  92.  
  93.     request is given with a data field of <key> syntax, then the
  94.  
  95.     supplied data will replace the record following the matching
  96.  
  97.     <keyname>.  If the keyname does not exist, the record will be
  98.  
  99.     appended to the named file.  The individual installation must
  100.  
  101.     provide the linkage between the <keyname> and the record it
  102.  
  103.     references.
  104.  
  105.  
  106.     In addition, the lookup(L) request will provide a list of keynames
  107.  
  108.     into a file (or the name of a file which contains the keynames).
  109.  
  110.  
  111.  
  112.  
  113.  
  114.                                                                 [Page 2]
  115.  
  116. NWG/RFC #133
  117.  
  118.  
  119. 1B2 Transaction code F (request File directory) requests a listing of
  120.  
  121.     available files.  The data field of the F transaction is of the
  122.  
  123.     form:  <pathname>GS<pathname>GS...  All files in the server system
  124.  
  125.     which match one or move of the given <pathname> specifiers are
  126.  
  127.     listed in a return file.  The format of the data fiels of this
  128.  
  129.     file is:  <pathname>GS<pathname>GS...  If a <pathname> field in
  130.  
  131.     the request transaction does not include a <name> field, the
  132.  
  133.     default is all files on the given device.  Some examples are given:
  134.  
  135.     <F><DC1 DSK[62,50]] GS JOE>
  136.  
  137.     This example requests a list of all files on the disk specified by
  138.  
  139.     [62,50] plus all files named JOE.  The response could contain in
  140.  
  141.     the data field:
  142.  
  143.     <DC1 DSK[62,50] RS ALPHA RS BETA RS JOE GS DC1DSK[10,50] RS JOE>
  144.  
  145.     This message states that in the [62,50] area of the disk there are
  146.  
  147.     files ALPHA, BETA, and JOE, and that JOE is also a file in the
  148.  
  149.     [10,50] area of the disk.
  150.  
  151.  
  152. 2   ERROR RECOVERY
  153.  
  154.  
  155. 2A  Error recovery procedures have been noticeably lacking to date.
  156.  
  157.     The usual approach has been to close the connection and start from
  158.  
  159.     scratch.  Mr Bhushan proposes a third level abort but doesn't
  160.  
  161.     really detail the implementation.  I propose a multilevel error
  162.  
  163.     recovery procedure as follows.
  164.  
  165.  
  166. 2B  If an error occurs which does not cause a loss of third level
  167.  
  168.  
  169.  
  170.                                                                 [Page 3]
  171.  
  172. NWG/RFC #133
  173.  
  174.  
  175.     transaction boundaries and only affects one side of a duplex
  176.  
  177.     connection, a third level recovery is possible via a transaction
  178.  
  179.     sequence abort.  An example is given:
  180.  
  181.     User                Server          Comments
  182.     <R><...>    ==>                     Send me this file
  183.                 <==     <rs>            Ok, I've got it
  184.     <rr>        ==>                     Ready
  185.                 <==     <*><...error>   Here it is (with an error)
  186.     <-><D>      ==>                     No.  (data) error
  187.                 <==     <-><D>          Sorry, forget it
  188.     <R><...>    ==>                     Send the file (again)
  189.                 |<==    <rs>            Ready (doesn't get there)
  190.                 ...                     (waiting)
  191.     <-><0>      ==>                     Error, timeout
  192.                 <==     <-><0>          Sorry, forget it
  193.     <R><...>    ==>                     Send the file (third time)
  194.                 <==     <rs>            Got it
  195.     <rr>        ==>                     Ready
  196.                 <==     <*><...>        There it is
  197.     <rr>        ==>                     Got it
  198.                 <==     <+>             Done (finally>
  199.  
  200.     Note that the server always gets the last word in error situations
  201.  
  202.     as well as normal transmission.
  203.  
  204.  
  205. 2C  Although the above examples are given in terms of Bhushan's
  206.  
  207.     transaction codes, this form of error recovery is implementable in
  208.  
  209.     any protocol which uses flagged blocking and duplex connections.
  210.  
  211.  
  212. 2D  If errors cannot be recovered as above, then some meanst must be
  213.  
  214.     available to clear the link completely and resynchronize.  I
  215.  
  216.     suggest that an 8-bit argument be appended to the interrupt-on-link
  217.  
  218.     NCP message (INR, INS).  The receiver would send <INR><error> to
  219.  
  220.     indicate that the block boundaries were lost and all incoming data
  221.  
  222.     is being discarded.  The sender, upon receiving the INR, would
  223.  
  224.  
  225.  
  226.                                                                 [Page 4]
  227.  
  228. NWG/RFC #133
  229.  
  230.  
  231.     flush all queued output and wait for the link to clear.  The NCP
  232.  
  233.     would then send a <INS><newsync> message and, when it was received
  234.  
  235.     (RFNM returned), a negative termination would be sent on the link.
  236.  
  237.     The receiver begins accepting data again when the INS is received.
  238.  
  239.     This assumed that any process can flush untransmitted data and
  240.  
  241.     detect a clear link.  Note that this method is useable on any
  242.  
  243.     simplex connection.
  244.  
  245.  
  246. 2E  If all else fails, one can resort to closing the faulty socket.
  247.  
  248.  
  249. 3   NCP VERSION NUMBERS
  250.  
  251. 3A  I suggest that the NCP be given a version number and the next
  252.  
  253.     version include two new message types:
  254.  
  255.         <WRU> ('Who aRe yoU?')  requests a version number from the
  256.  
  257.     receiving host and  <IAM><version> ('I AM')     supplies that
  258.  
  259.     number.
  260.  
  261.  
  262. 3B  The messages would probably be initially used in a 'can I talk to
  263.  
  264.     you?' sense or not at all.  Eventually, it would take on a 'what
  265.  
  266.     can you do?' meaning.  Accordingly, the <version> field should be
  267.  
  268.     large (32 bits?) for expansion.
  269.  
  270.  
  271.  
  272.        [ This RFC was put into machine readable form for entry ]
  273.           [ into the online RFC archives by Jose Tamayo 4/97 ]
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.                                                                 [Page 5]
  283.  
  284.