Movatterモバイル変換

Network Working Group                        A.Shoshani, SDCRequest for Comment # 197                   E. Harslem, RandNIC # 7142                                      14 July 1971Categories:  C.3, D.1Updates:  NoneObsoletes:  NoneINITIAL CONNECTION PROTOCOL--REVIEWEDINTRODUCTION------------     At the Network meeting preceding the SJCC '71, an"ICP Committee" was established.  It's purpose was to get"something" working fast with minimum modifications to thecurrent ICP so as to minimize complaints.  (This seems likea good definition for almost everything!)  Consequently,those who had objections to the current ICP were interviewedand a compromise was reached in the form of RFC #165.  TheICP committee didn't have a chance to think about an alter-native because of the above mentioned constraints.  In thisnote we attempted a simple version of an ICP assuming thatwe can add commands to Host-Host protocol. We hope that thiswill be useful in the design of the next version of theHost-Host protocol.ICP COMMANDS------------     To establish a regular connection one party can issuean INIT (NCP sends RTS or STR commands), then the otherparty can accept the request for connection by respondingwith an INIT or refusing it with a CLOSE.  We think that                                                                [Page 1]

a similar, simple mechanism is desirable for the ICP.Furthermore, the ICP should allow for simplex as well asduplex connections from user to server.     The following commands are necessary for simplexconnections:     ISC - Initiate Simplex Connection     ASC - Accept Simplex Connection     RSC - Refuse Simplex Connection     The notation for parameters is similar to thatof RFC #165:     L - Server socket name, in one special case the         server is "logger".     U - User socket.     S - Socket assigned by server for the connection         with user.     X - Is the byte size if U is odd and is the link         number if U is even.     -                           -     X - Is the complement of X (X is the link number         if U is odd and byte size if U is even.     To initiate a simplex connection the user's NCPissues:           ISC, L, U, X     To refuse this connection the server's NCP issues:           RSC, L, U                                                                [Page 2]

     To accept this connection the server's NCP issues:                         -           ASC, L, U, S, X     Similarly, for duplex connections, we have:           IDC, L, U1, X1, U2, X2           RDC, L, U1, U2                           -           -           ADC, L, U1, S1, X1, U2, S2, X2where (U1,U2), (S1,S2), (U1,S1) and (U2,S2) are pairs ofopposite gender.     After the server accepts the connection(s), it (they)goes immediately to a "connected state", and the appropriateALL command(s) must be sent.ADVANTAGES----------     The main advantage to this approach is that it mini-mizes the dialog between user and server.  The server socketL is used only as an address, not a socket to connect to,therefore eliminating the need to establish a connection toL, choose a byte size, send an ALL command, send and receivedata on it and CLOSE it.  Race conditions as mentioned inRFC #143 do not arise.  Socket L is the server and shouldbe in a "Listening for ICP" state when an ISC or IDC isreceived.  If socket L is not in that state, the servingNCP should refuse to ICP request.  The serving NCP should_not_ queue ICP requests.     In the current ICP, when the user choses socket U, hehas to reserve sockets U+2 and U+3.  In the above describedapproach no restrictions exist for U1 and U2 (except thatthey are of opposite gender);  the same is true for S1 andS2.     We think that duplex commands are necessary since bothconnections are to be connected to the same server process.Their separation by using two ISCs, will add complicationsof correlating the two ISCs with the same process.  Also,if two ISCs are used, the first might be accepted and thesecond refused.  This leads to uncertainty on the user'spart.  This condition cannot occur with the duplex commands.                                                                [Page 3]

MINIMUM MODIFICATION TO CURRENT ICP-----------------------------------     The minimum change we can think of to make the currentICP look similar to the above is to add one NCP level com-mand -- accept:           ACC, L, U, S     The exchange between NCPs in the notation of RFC #165is now:<where the original uses a script lowercase "L" we use "l"><where the original uses subscripts we use {} so that   A-subscript-B is printed A{B} >     Server NCP                   User NCP     ----------                   --------     Listen for connection on L   RST,U,L,l{A}     ACC,L,U,S                    S is passed by NCP to the                                  user and connection from                                  U to L is closed.     STR,S+1,U+2,B{s}             STR,U+3,S,B{u}     RTS,S,U+3,l{B}               RTS,U+2,S+1,l{c}     Wait for connection          Wait for connection     ALL,l{B},m{B},b{B}           ALL,l{c},m{c},b{c}     An alternative way to the ACC command is a CLS commandwith an additional parameter (32 bits long).  If parameteris zero the request for connection by the user is refused;if the parameter is non-zero, the request is accepted andsocket S is the value of the parameter.     All suggested changes improve the ICP dialog both fromthe aesthetic and efficiency points of view.  We lean strongly,however, to the first, more major ICP modification.                                                                [Page 4]

A COMMENT ABOUT CLS COMMAND---------------------------     It seems appropriate to mention here for the purposeof the next version of the Host-Host protocol that theCLS command has more than one function.  We think that theCLS command should be reserved to close connections in the"connected state" only (i.e., "open" connections).  Twoadditional commands can be used for "refusing" and "reject-ing" requests for connections:           REJ<mysocket><yoursocket> -- when a request           for connection is rejected unconditionally.           REF<mysocket><yoursocket><reason> -- when a           request for connection is refused temporarily           because the NCP could not handle it.  For           example:  no process LISTENed to it and it           was timed-out, or NCP tables are full in which           case the user process may try again.  The           reason for refusing is indicated in the           parameter "reason".[ This RFC was put into machine readable form for entry ][ into the online RFC archives by BBN Corp. under the   ][ direction of Alex McKenzie.                   12/96   ]                                                                [Page 5]