home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 1 / rfc0163.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  5.3 KB  |  166 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                            V. Cerf
  8. Request for Comments #163                        19 May 71
  9. NIC #6775                                        UCLA - NMC
  10. Categories:  D.7                                 Computer Science
  11. Updates:  None
  12. Obsoletes:  None
  13.  
  14.  
  15.                         DATA TRANSFER PROTOCOLS
  16.  
  17. This is an informal statement of material discussed at the SJCC.  There
  18. are two peoblems.
  19.  
  20.    1.  Movement of data from one site to another.
  21.    2.  Interpretation of the data at receiving site.
  22.  
  23. The first task (1) requires a simple protocol which accomplishes the
  24. following
  25.  
  26.    1)  Standard connection procedure for connecting
  27.        transmitting and receiving processes
  28.  
  29.    2)  Standard packaging which allows network to
  30.        collect the transmitted data stream in the
  31.        right order and know when the end of the
  32.        file has been reached.
  33.  
  34. Standard Connection Procedure
  35.  
  36. Suppose every HOST has a process charged with the responsibility of
  37. sending and receiving files between -HOSTS-(processes?)[The Data
  38. Manager].  If the Data Manager offers to listen on a given socket for
  39. file xmt requests, then ICP is sufficient to establish a connection
  40. between a serving Data Manager and a using process.
  41.  
  42. We have completely avoided the discussion of data interpretation, and
  43. also the problem of control.  For instance, we have not said how a
  44. process can ask the Data Manager to send a file of a par- ticular name,
  45. nor how to end the transmission of a file.  This is deferred for later.
  46.  
  47. Another desirable ability is to have processes transmit files to each
  48. other independent of the HOST Data Manager.  ICP should suffice, for the
  49. creation of a full duplex connection.  File naming, and format
  50. interpretation are left to the individual process to solve.
  51.  
  52. It is of interest to note that files need not have names.  If two
  53. processes are connected, then the file name is in a sense implicit in
  54. the sending and receiving socket pair.  One imagines, however, that
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. connections with Data Managers for the purpose of file transmission are
  61. too transient to serve as permanent file names, so information about
  62. file name will be needed by the Data Manager.  This information could be
  63. supplied either embedded in the file transmission data stream, or
  64. supplied over a separate control connection established at ICP time.
  65.  
  66. It seems reasonable that a Data Manager have a network-wide, fixed
  67. socket number on which it is listening to service data transmission
  68. requests.* In this sense, it acts much like the Network Logger.  For
  69. inter-process file transmission, less rigidity seems called for, and we
  70. can leave such decisions to the individual peocesses communicating with
  71. each other.  Public processes at serving HOSTS could have known (nia
  72. NIC?) sockets over which file transmission is acceptable.
  73.  
  74. Standard Packaging
  75.  
  76. We naively imagine that very little in the way of formatting is needed
  77. to move data across the connection.  A few bits (8?) at the beginning of
  78. transmission could specify the formatting protocol (e.g. arbitrary bit
  79. string until connection closed, count field + data, break chars, etc.)
  80. Depending on the selected format mode, the appropriate control bits will
  81. or will not appear interspersed betweeen the data bits.  Message
  82. boundaries are totally transparent.
  83.  
  84. A way of ending the file, possibly without closing the connection, is
  85. useful, although closing the connection after the RFNM from final
  86. "record" sent is received by the sending process might be adequate
  87. (sufficient, but not palatable?)
  88.  
  89. ----
  90. *ICP causes sockets to be dynamically assigned for the ensuing
  91. conversation (which might be all 1-way).
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113. Control
  114.  
  115. A great many problems come up if the Data Manager serves as a part of
  116. the HOST filling system.  For example, the Data Manager must know
  117. whether the process it is serving wants to send a file or receive one.
  118. In either case, some sort of file name + qualifiers (user ID, security
  119. codes, access requested, etc.) will be needed to resolve the usual
  120. access legality, and potential file name ambiguities.  This information
  121. can be supplied either within a single full duplex data stream (1 per
  122. ICP request) established by a modified ICP for data transmission.  The
  123. former seems simplier, sufficient, and immediately implementable.
  124.  
  125. Data transmission between arbitrary processes probably does not need as
  126. much formal control protocol as process-to/from-DM (data Manager)
  127. connection.  Ad hoc procedures can be established by trading information
  128. on previously established connections; regularity is nice, so perhaps a
  129. standard set of control protocols can be devised which work, regardless
  130. of the identity of the processes transmitting data.  Control data must
  131. be formatted and probably identifiable by prefix codes so that
  132. unnecessary control information can be left out if desired.  (I am
  133. thinking specifically of file names.)
  134.  
  135. It remains to establish a set of format protocols which permit packaging
  136. of data and identification of control information.  This should be the
  137. task of the renamed Data Transmission Committee.
  138.  
  139.        [ This RFC was put into machine readable form for entry ]
  140.          [ into the online RFC archives by Simone Demmel 5/97 ]
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.                                                                 [Page 3]
  165.  
  166.