home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 100s / rfc197.txt < prev   
Text File  |  1997-03-04  |  7KB  |  272 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                        A.Shoshani, SDC
  8. Request for Comment # 197                   E. Harslem, Rand
  9. NIC # 7142                                      14 July 1971
  10. Categories:  C.3, D.1
  11. Updates:  None
  12. Obsoletes:  None
  13.  
  14.          INITIAL CONNECTION PROTOCOL--REVIEWED
  15.  
  16. INTRODUCTION
  17. ------------
  18.  
  19.      At the Network meeting preceding the SJCC '71, an
  20. "ICP Committee" was established.  It's purpose was to get
  21. "something" working fast with minimum modifications to the
  22. current ICP so as to minimize complaints.  (This seems like
  23. a good definition for almost everything!)  Consequently,
  24. those who had objections to the current ICP were interviewed
  25. and a compromise was reached in the form of RFC #165.  The
  26. ICP committee didn't have a chance to think about an alter-
  27. native because of the above mentioned constraints.  In this
  28. note we attempted a simple version of an ICP assuming that
  29. we can add commands to Host-Host protocol. We hope that this
  30. will be useful in the design of the next version of the
  31. Host-Host protocol.
  32.  
  33. ICP COMMANDS
  34. ------------
  35.  
  36.      To establish a regular connection one party can issue
  37. an INIT (NCP sends RTS or STR commands), then the other
  38. party can accept the request for connection by responding
  39. with an INIT or refusing it with a CLOSE.  We think that
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. a similar, simple mechanism is desirable for the ICP.
  61. Furthermore, the ICP should allow for simplex as well as
  62. duplex connections from user to server.
  63.  
  64.      The following commands are necessary for simplex
  65. connections:
  66.  
  67.      ISC - Initiate Simplex Connection
  68.  
  69.      ASC - Accept Simplex Connection
  70.  
  71.      RSC - Refuse Simplex Connection
  72.  
  73.      The notation for parameters is similar to that
  74. of RFC #165:
  75.  
  76.      L - Server socket name, in one special case the
  77.          server is "logger".
  78.  
  79.      U - User socket.
  80.  
  81.      S - Socket assigned by server for the connection
  82.          with user.
  83.  
  84.      X - Is the byte size if U is odd and is the link
  85.          number if U is even.
  86.  
  87.      -                           -
  88.      X - Is the complement of X (X is the link number
  89.          if U is odd and byte size if U is even.
  90.  
  91.      To initiate a simplex connection the user's NCP
  92. issues:
  93.            ISC, L, U, X
  94.  
  95.      To refuse this connection the server's NCP issues:
  96.  
  97.            RSC, L, U
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113.      To accept this connection the server's NCP issues:
  114.                          -
  115.            ASC, L, U, S, X
  116.  
  117.      Similarly, for duplex connections, we have:
  118.  
  119.            IDC, L, U1, X1, U2, X2
  120.  
  121.            RDC, L, U1, U2
  122.                            -           -
  123.            ADC, L, U1, S1, X1, U2, S2, X2
  124.  
  125. where (U1,U2), (S1,S2), (U1,S1) and (U2,S2) are pairs of
  126. opposite gender.
  127.  
  128.      After the server accepts the connection(s), it (they)
  129. goes immediately to a "connected state", and the appropriate
  130. ALL command(s) must be sent.
  131.  
  132. ADVANTAGES
  133. ----------
  134.  
  135.      The main advantage to this approach is that it mini-
  136. mizes the dialog between user and server.  The server socket
  137. L is used only as an address, not a socket to connect to,
  138. therefore eliminating the need to establish a connection to
  139. L, choose a byte size, send an ALL command, send and receive
  140. data on it and CLOSE it.  Race conditions as mentioned in
  141. RFC #143 do not arise.  Socket L is the server and should
  142. be in a "Listening for ICP" state when an ISC or IDC is
  143. received.  If socket L is not in that state, the serving
  144. NCP should refuse to ICP request.  The serving NCP should
  145. _not_ queue ICP requests.
  146.  
  147.      In the current ICP, when the user choses socket U, he
  148. has to reserve sockets U+2 and U+3.  In the above described
  149. approach no restrictions exist for U1 and U2 (except that
  150. they are of opposite gender);  the same is true for S1 and
  151. S2.
  152.  
  153.      We think that duplex commands are necessary since both
  154. connections are to be connected to the same server process.
  155. Their separation by using two ISCs, will add complications
  156. of correlating the two ISCs with the same process.  Also,
  157. if two ISCs are used, the first might be accepted and the
  158. second refused.  This leads to uncertainty on the user's
  159. part.  This condition cannot occur with the duplex commands.
  160.  
  161.  
  162.  
  163.  
  164.                                                                 [Page 3]
  165.  
  166. MINIMUM MODIFICATION TO CURRENT ICP
  167. -----------------------------------
  168.  
  169.      The minimum change we can think of to make the current
  170. ICP look similar to the above is to add one NCP level com-
  171. mand -- accept:
  172.  
  173.            ACC, L, U, S
  174.  
  175.      The exchange between NCPs in the notation of RFC #165
  176. is now:
  177. <where the original uses a script lowercase "L" we use "l">
  178. <where the original uses subscripts we use {} so that
  179.    A-subscript-B is printed A{B} >
  180.  
  181.      Server NCP                   User NCP
  182.      ----------                   --------
  183.  
  184.      Listen for connection on L   RST,U,L,l{A}
  185.  
  186.      ACC,L,U,S                    S is passed by NCP to the
  187.                                   user and connection from
  188.                                   U to L is closed.
  189.  
  190.      STR,S+1,U+2,B{s}             STR,U+3,S,B{u}
  191.  
  192.      RTS,S,U+3,l{B}               RTS,U+2,S+1,l{c}
  193.  
  194.      Wait for connection          Wait for connection
  195.  
  196.      ALL,l{B},m{B},b{B}           ALL,l{c},m{c},b{c}
  197.  
  198.  
  199.      An alternative way to the ACC command is a CLS command
  200. with an additional parameter (32 bits long).  If parameter
  201. is zero the request for connection by the user is refused;
  202. if the parameter is non-zero, the request is accepted and
  203. socket S is the value of the parameter.
  204.  
  205.      All suggested changes improve the ICP dialog both from
  206. the aesthetic and efficiency points of view.  We lean strongly,
  207. however, to the first, more major ICP modification.
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.                                                                 [Page 4]
  218.  
  219. A COMMENT ABOUT CLS COMMAND
  220. ---------------------------
  221.  
  222.      It seems appropriate to mention here for the purpose
  223. of the next version of the Host-Host protocol that the
  224. CLS command has more than one function.  We think that the
  225. CLS command should be reserved to close connections in the
  226. "connected state" only (i.e., "open" connections).  Two
  227. additional commands can be used for "refusing" and "reject-
  228. ing" requests for connections:
  229.  
  230.            REJ<mysocket><yoursocket> -- when a request
  231.            for connection is rejected unconditionally.
  232.  
  233.            REF<mysocket><yoursocket><reason> -- when a
  234.            request for connection is refused temporarily
  235.            because the NCP could not handle it.  For
  236.            example:  no process LISTENed to it and it
  237.            was timed-out, or NCP tables are full in which
  238.            case the user process may try again.  The
  239.            reason for refusing is indicated in the
  240.            parameter "reason".
  241.  
  242.  
  243.  
  244.  
  245.  
  246. [ This RFC was put into machine readable form for entry ]
  247. [ into the online RFC archives by BBN Corp. under the   ]
  248. [ direction of Alex McKenzie.                   12/96   ]
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.                                                                 [Page 5]
  271.  
  272.