home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 100s / rfc167.txt < prev    next >
Text File  |  1997-05-19  |  8KB  |  228 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.                          Network Working Group
  8.                         Request for Comment #167
  9.                                NIC #6784
  10.  
  11.  
  12.  
  13.                     Socket Conventions Reconsidered
  14.  
  15.  
  16.  
  17.                           Athay Bhushan (MAC)
  18.                          Bob Metcalfe (Harvard)
  19.                             Joel Winett (LL)
  20.  
  21.                               24 May 1971
  22.  
  23.  
  24.  
  25.                           Category: C1, C3, C8
  26.                         Related RFCs: #147, #129
  27.                     Related Functional Documents: #1
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. RFC 167                                  Socket Conventions Reconsidered
  61.  
  62.  
  63. The current NCP Protocol says nothing about how hosts should assign
  64. socket numbers to process ports, except that the low-order bit is to
  65. specify socket gender (i.e., send or receive). Two recent proposals call
  66. for additional network-wide conventions on the 32-bit socket-number. The
  67. first proposal asks that a portion of the socket number be reserved for
  68. a network-unique user number for accounting and access control. The
  69. second proposal asks that the high-order 16 bits of the socket number be
  70. zero to assist smaller hosts in reducing the space required for socket
  71. number tables.
  72.  
  73. It is recommended that both of these proposals be set aside.  Because a
  74. large perturbation of the current NCP Protocol is required to provide
  75. adequate handles for accounting and access control, and because the
  76. socket number is already underpowered for its use, it is recommended
  77. that both proposals be set aside until serious consideration can be
  78. given to a major NCP Protocol overhaul.
  79.  
  80. DISCUSSION
  81.  
  82. The socket number, as it is used in the current NCP Protocol is a small
  83. number with a big function. It will probably be found that a
  84. substantially more powerful identification mechanism (e.g., a
  85. hierarchical naming scheme with arbitrarily long names) is required to
  86. satisfactorily manipulate process ports. Two features of such a
  87. mechanism will be (1) that it treats accounting and access control with
  88. the respect they deserve, and (2) that it is part of a simpler NCP
  89. Protocol more easily implemented under the existing size and complexity
  90. restrictions of smaller hosts.
  91.  
  92. Socket numbers are process port identifiers used in establishing
  93. connections between processes. It is essential that they be UNIQUE to
  94. avoid ambiguity during connection. It is important that their assignment
  95. to specific processes be REPEATABLE for reconnection on a regular basis.
  96.  
  97. To assure that process port identifiers are unique and repeatable it is
  98. necessary to subject their allocation to access controls.  The simplest
  99. of access controls assuring uniqueness is that provided by NCPs which
  100. check their tables of active connections for duplication when a process
  101. requests the use of a specific socket number.
  102.  
  103. There is real difficulty in constructing schemes for allowing socket
  104. number assignments to be repeatable. Some socket numbers are to be
  105. universally known and associated with processes operating with specified
  106. protocols (e.g., a logger socket, an RJB socket, a file transfer
  107. socket). Other socket numbers might not be universally known, but given
  108. to their users in a transmission over a universally known socket (e.g.,
  109. the socket pair specified by the transmission over the logger socket
  110. using the Initial Connection Protocol (ICP)).  Concurrently running
  111.  
  112.  
  113.  
  114.                                                                 [Page 2]
  115.  
  116. RFC 167                                  Socket Conventions Reconsidered
  117.  
  118.  
  119. instances of a program will require distinct process port identifiers.
  120. Therefore, socket numbers will in general need to be dynamically
  121. assigned via some system controlled allocation function.
  122.  
  123. There are a number of ways of providing for potentially repeatable
  124. socket number assignments. One bad way is to have the NCP keep a list of
  125. all assigned socket numbers with some indication of who is permitted to
  126. use them and for how long -- like keeping track of magnetic tape reels.
  127. If there were few available socket numbers (e.g., 16 bits worth) this
  128. bad method or one comparably distasteful and logistically foreboding
  129. would have to be adopted.  With an abundance of socket numbers it is
  130. possible, using sparse socket number assignment, to devise simple
  131. algorithms for deciding whether a socket numbers being requested by a
  132. process can be allocated freely. Such algorithms might take into account
  133. (1) the dynamic status of the socket (i.e., its association with a
  134. currently active connection), (2) its reserved status as a standard
  135. service port address, and (3) its access control attributes in relation
  136. to those of the requesting process.
  137.  
  138. One good strategy for controlling socket numbers is to partition the
  139. full socket space at a host among its network users. Under this scheme a
  140. user could be assured of having the repeatable use of his partition.  It
  141. might also be helpful to designate a utility partition for use in socket
  142. number allocations where repeatability is not essential. Such socket
  143. numbers could be selected from the utility partition by some clever
  144. construction on the date and time.
  145.  
  146. It will often be the case that a program will be written to use several
  147. connections. Remembering that this program might find itself being
  148. executed concurrently by several processes belonging to several users,
  149. it might be convenient to code with socket tags which are to be extended
  150. with runtime user and process identifier fields.
  151.  
  152. Socket numbers will tend to be viewed -- should be viewed -- as having
  153. three fields: a user field to assist in providing repeatability, a
  154. process field to assure uniqueness for concurrent instances of a
  155. program, and a tag field to enable the convenient referencing of
  156. multiple connections to a single process.
  157.  
  158. Although fields will be helpful in dealing with socket number
  159. allocation, it is not essential that such field designations be uniform
  160. over the network. In all network transactions the 32-bit socket number
  161. is handled with its 8-bit host number. Thus, if hosts are able to
  162. maintain uniqueness and repeatability internally, socket numbers in the
  163. network as a whole will also be unique and repeatable.  If a host fails
  164. to do so, only connections with that offending host are affected.
  165.  
  166.  
  167.  
  168.  
  169.  
  170.                                                                 [Page 3]
  171.  
  172. RFC 167                                  Socket Conventions Reconsidered
  173.  
  174.  
  175. Because the size, use, and character of systems on the network are so
  176. varied, it would be difficult if not impossible to come up with an
  177. agreed upon particular division of the 32-bit socket number.  Hosts have
  178. different internal restrictions on the number of users, processes per
  179. user, and connections per process they will permit.
  180.  
  181. It has been suggested that it may not be necessary to maintain socket
  182. uniqueness. It is contended that there is really no significant use made
  183. of the socket number after a connection has been established. The only
  184. reason a host must now save a socket number for the life of a connection
  185. is to include it in the CLOSE of that connection. If such is really the
  186. case, then the NCP Protocol might be improved by inventing a new CLOSE
  187. which uses the host-line pair associated with the connection. Hosts
  188. which are short on space could then forget a socket number immediately
  189. after successful connection.
  190.  
  191.        [ This RFC was put into machine readable form for entry ]
  192.         [ into the online RFC archives by Thomas Nielsen 5/97 ]
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.                                                                 [Page 4]
  227.  
  228.