Socket conventions reconsidered (RFC0167)
Original Publication Date: 1971-May-01
Included in the Prior Art Database: 2019-Feb-10
Internet Society Requests For Comment (RFCs)
A.K. Bhushan: AUTHOR [+2]
Network Working Group Request for Comment #167 NIC #6784
Socket Conventions Reconsidered
Athay Bhushan (MAC) Bob Metcalfe (Harvard) Joel Winett (LL)
24 May 1971
Category: C1, C3, C8 Related RFCs: #147, #129 Related Functional Documents: #1
RFC 167 Socket Conventions Reconsidered
The current NCP Protocol says nothing about how hosts should assign socket numbers to process ports, except that the low-order bit is to specify socket gender (i.e., send or receive). Two recent proposals call for additional network-wide conventions on the 32-bit socket-number. The first proposal asks that a portion of the socket number be reserved for a network-unique user number for accounting and access control. The second proposal asks that the high-order 16 bits of the socket number be zero to assist smaller hosts in reducing the space required for socket number tables.
It is recommended that both of these proposals be set aside. Because a large perturbation of the current NCP Protocol is required to provide adequate handles for accounting and access control, and because the socket number is already underpowered for its use, it is recommended that both proposals be set aside until serious consideration can be given to a major NCP Protocol overhaul.
The socket number, as it is used in the current NCP Protocol is a small number with a big function. It will probably be found that a substantially more powerful identification mechanism (e.g., a hierarchical naming scheme with arbitrarily long names) is required to satisfactorily manipulate process ports. Two features of such a mechanism will be (1) that it treats accounting and access control with the respect they deserve, and (2) that it is part of a simpler NCP Protocol more easily implemented under the existing size and complexity restrictions of smaller hosts.
Socket numbers are process port identifiers used in establishing connections between processes. It is essential that they be UNIQUE to avoid ambiguity during connection. It is important that their assignment to specific processes be REPEATABLE for reconnection on a regular basis.
To assure that process port identifiers are unique and repeatable it is necessary to subject their allocation to access controls. The simplest of access controls assuring uniqueness is that provided by NCPs which check their tables of active connections for duplication when a process requests the use of a specific socket number.
There is real difficulty in constructing schemes for allowing socket number assignments to be repeatable. Some socket numbers are to be universally known and associated with processes operating with specified protocols (e.g., a logger socket, an RJB socket, a file transfer socket). Other socket numbers might not be universally known, but given to their users in a transmission over a universally known socket (e.g., the socket pair specified by the transmission over the logger socket using the Initial Connection Protocol (ICP)). Concurrentl...