Movatterモバイル変換

Network Working Group                            V. CerfRequest for Comments #163                        19 May 71NIC #6775                                        UCLA - NMCCategories:  D.7                                 Computer ScienceUpdates:  NoneObsoletes:  NoneDATA TRANSFER PROTOCOLSThis is an informal statement of material discussed at the SJCC.  Thereare two peoblems.   1.  Movement of data from one site to another.   2.  Interpretation of the data at receiving site.The first task (1) requires a simple protocol which accomplishes thefollowing   1)  Standard connection procedure for connecting       transmitting and receiving processes   2)  Standard packaging which allows network to       collect the transmitted data stream in the       right order and know when the end of the       file has been reached.Standard Connection ProcedureSuppose every HOST has a process charged with the responsibility ofsending and receiving files between -HOSTS-(processes?)[The DataManager].  If the Data Manager offers to listen on a given socket forfile xmt requests, then ICP is sufficient to establish a connectionbetween a serving Data Manager and a using process.We have completely avoided the discussion of data interpretation, andalso the problem of control.  For instance, we have not said how aprocess can ask the Data Manager to send a file of a par- ticular name,nor how to end the transmission of a file.  This is deferred for later.Another desirable ability is to have processes transmit files to eachother independent of the HOST Data Manager.  ICP should suffice, for thecreation of a full duplex connection.  File naming, and formatinterpretation are left to the individual process to solve.It is of interest to note that files need not have names.  If twoprocesses are connected, then the file name is in a sense implicit inthe sending and receiving socket pair.  One imagines, however, that                                                                [Page 1]

connections with Data Managers for the purpose of file transmission aretoo transient to serve as permanent file names, so information aboutfile name will be needed by the Data Manager.  This information could besupplied either embedded in the file transmission data stream, orsupplied over a separate control connection established at ICP time.It seems reasonable that a Data Manager have a network-wide, fixedsocket number on which it is listening to service data transmissionrequests.* In this sense, it acts much like the Network Logger.  Forinter-process file transmission, less rigidity seems called for, and wecan leave such decisions to the individual peocesses communicating witheach other.  Public processes at serving HOSTS could have known (niaNIC?) sockets over which file transmission is acceptable.Standard PackagingWe naively imagine that very little in the way of formatting is neededto move data across the connection.  A few bits (8?) at the beginning oftransmission could specify the formatting protocol (e.g. arbitrary bitstring until connection closed, count field + data, break chars, etc.)Depending on the selected format mode, the appropriate control bits willor will not appear interspersed betweeen the data bits.  Messageboundaries are totally transparent.A way of ending the file, possibly without closing the connection, isuseful, although closing the connection after the RFNM from final"record" sent is received by the sending process might be adequate(sufficient, but not palatable?)----*ICP causes sockets to be dynamically assigned for the ensuingconversation (which might be all 1-way).                                                                [Page 2]

ControlA great many problems come up if the Data Manager serves as a part ofthe HOST filling system.  For example, the Data Manager must knowwhether the process it is serving wants to send a file or receive one.In either case, some sort of file name + qualifiers (user ID, securitycodes, access requested, etc.) will be needed to resolve the usualaccess legality, and potential file name ambiguities.  This informationcan be supplied either within a single full duplex data stream (1 perICP request) established by a modified ICP for data transmission.  Theformer seems simplier, sufficient, and immediately implementable.Data transmission between arbitrary processes probably does not need asmuch formal control protocol as process-to/from-DM (data Manager)connection.  Ad hoc procedures can be established by trading informationon previously established connections; regularity is nice, so perhaps astandard set of control protocols can be devised which work, regardlessof the identity of the processes transmitting data.  Control data mustbe formatted and probably identifiable by prefix codes so thatunnecessary control information can be left out if desired.  (I amthinking specifically of file names.)It remains to establish a set of format protocols which permit packagingof data and identification of control information.  This should be thetask of the renamed Data Transmission Committee.       [ This RFC was put into machine readable form for entry ]         [ into the online RFC archives by Simone Demmel 5/97 ]                                                                [Page 3]