Socket conventions reconsidered
RFC 167

Document Type RFC - Unknown (May 1971; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 167 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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

                                                                [Page 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)).  Concurrently running

                                                                [Page 2]
RFC 167                                  Socket Conventions Reconsidered

instances of a program will require distinct process port identifiers.
Therefore, socket numbers will in general need to be dynamically
assigned via some system controlled allocation function.

There are a number of ways of providing for potentially repeatable
socket number assignments. One bad way is to have the NCP keep a list of
all assigned socket numbers with some indication of who is permitted to
use them and for how long -- like keeping track of magnetic tape reels.
If there were few available socket numbers (e.g., 16 bits worth) this
bad method or one comparably distasteful and logistically foreboding
would have to be adopted.  With an abundance of socket numbers it is
possible, using sparse socket number assignment, to devise simple
algorithms for deciding whether a socket numbers being requested by a
process can be allocated freely. Such algorithms might take into account
(1) the dynamic status of the socket (i.e., its association with a
currently active connection), (2) its reserved status as a standard
service port address, and (3) its access control attributes in relation
to those of the requesting process.

One good strategy for controlling socket numbers is to partition the
full socket space at a host among its network users. Under this scheme a
user could be assured of having the repeatable use of his partition.  It
might also be helpful to designate a utility partition for use in socket
Show full document text