Movatterモバイル変換

                         Network Working Group                        Request for Comment #167                               NIC #6784                    Socket Conventions Reconsidered                          Athay Bhushan (MAC)                         Bob Metcalfe (Harvard)                            Joel Winett (LL)                              24 May 1971Category: C1, C3, C8Related RFCs: #147, #129Related Functional Documents: #1                                                                [Page 1]

RFC 167                                  Socket Conventions ReconsideredThe current NCP Protocol says nothing about how hosts should assignsocket numbers to process ports, except that the low-order bit is tospecify socket gender (i.e., send or receive). Two recent proposals callfor additional network-wide conventions on the 32-bit socket-number. Thefirst proposal asks that a portion of the socket number be reserved fora network-unique user number for accounting and access control. Thesecond proposal asks that the high-order 16 bits of the socket number bezero to assist smaller hosts in reducing the space required for socketnumber tables.It is recommended that both of these proposals be set aside.  Because alarge perturbation of the current NCP Protocol is required to provideadequate handles for accounting and access control, and because thesocket number is already underpowered for its use, it is recommendedthat both proposals be set aside until serious consideration can begiven to a major NCP Protocol overhaul.DISCUSSIONThe socket number, as it is used in the current NCP Protocol is a smallnumber with a big function. It will probably be found that asubstantially more powerful identification mechanism (e.g., ahierarchical naming scheme with arbitrarily long names) is required tosatisfactorily manipulate process ports. Two features of such amechanism will be (1) that it treats accounting and access control withthe respect they deserve, and (2) that it is part of a simpler NCPProtocol more easily implemented under the existing size and complexityrestrictions of smaller hosts.Socket numbers are process port identifiers used in establishingconnections between processes. It is essential that they be UNIQUE toavoid ambiguity during connection. It is important that their assignmentto specific processes be REPEATABLE for reconnection on a regular basis.To assure that process port identifiers are unique and repeatable it isnecessary to subject their allocation to access controls.  The simplestof access controls assuring uniqueness is that provided by NCPs whichcheck their tables of active connections for duplication when a processrequests the use of a specific socket number.There is real difficulty in constructing schemes for allowing socketnumber assignments to be repeatable. Some socket numbers are to beuniversally known and associated with processes operating with specifiedprotocols (e.g., a logger socket, an RJB socket, a file transfersocket). Other socket numbers might not be universally known, but givento their users in a transmission over a universally known socket (e.g.,the socket pair specified by the transmission over the logger socketusing the Initial Connection Protocol (ICP)).  Concurrently running                                                                [Page 2]

RFC 167                                  Socket Conventions Reconsideredinstances of a program will require distinct process port identifiers.Therefore, socket numbers will in general need to be dynamicallyassigned via some system controlled allocation function.There are a number of ways of providing for potentially repeatablesocket number assignments. One bad way is to have the NCP keep a list ofall assigned socket numbers with some indication of who is permitted touse them and for how long -- like keeping track of magnetic tape reels.If there were few available socket numbers (e.g., 16 bits worth) thisbad method or one comparably distasteful and logistically forebodingwould have to be adopted.  With an abundance of socket numbers it ispossible, using sparse socket number assignment, to devise simplealgorithms for deciding whether a socket numbers being requested by aprocess can be allocated freely. Such algorithms might take into account(1) the dynamic status of the socket (i.e., its association with acurrently active connection), (2) its reserved status as a standardservice port address, and (3) its access control attributes in relationto those of the requesting process.One good strategy for controlling socket numbers is to partition thefull socket space at a host among its network users. Under this scheme auser could be assured of having the repeatable use of his partition.  Itmight also be helpful to designate a utility partition for use in socketnumber allocations where repeatability is not essential. Such socketnumbers could be selected from the utility partition by some cleverconstruction on the date and time.It will often be the case that a program will be written to use severalconnections. Remembering that this program might find itself beingexecuted concurrently by several processes belonging to several users,it might be convenient to code with socket tags which are to be extendedwith runtime user and process identifier fields.Socket numbers will tend to be viewed -- should be viewed -- as havingthree fields: a user field to assist in providing repeatability, aprocess field to assure uniqueness for concurrent instances of aprogram, and a tag field to enable the convenient referencing ofmultiple connections to a single process.Although fields will be helpful in dealing with socket numberallocation, it is not essential that such field designations be uniformover the network. In all network transactions the 32-bit socket numberis handled with its 8-bit host number. Thus, if hosts are able tomaintain uniqueness and repeatability internally, socket numbers in thenetwork as a whole will also be unique and repeatable.  If a host failsto do so, only connections with that offending host are affected.                                                                [Page 3]

RFC 167                                  Socket Conventions ReconsideredBecause the size, use, and character of systems on the network are sovaried, it would be difficult if not impossible to come up with anagreed upon particular division of the 32-bit socket number.  Hosts havedifferent internal restrictions on the number of users, processes peruser, and connections per process they will permit.It has been suggested that it may not be necessary to maintain socketuniqueness. It is contended that there is really no significant use madeof the socket number after a connection has been established. The onlyreason a host must now save a socket number for the life of a connectionis to include it in the CLOSE of that connection. If such is really thecase, then the NCP Protocol might be improved by inventing a new CLOSEwhich uses the host-line pair associated with the connection. Hostswhich are short on space could then forget a socket number immediatelyafter successful connection.       [ This RFC was put into machine readable form for entry ]        [ into the online RFC archives by Thomas Nielsen 5/97 ]                                                                [Page 4]