RFC 129 (rfc129) - Page 2 of 6

Request for comments on socket name structure

The second format shown above associates sockets specifi-
cally with users as opposed to processes.
     The following discussion covers three different schemes
of socket identifier assignment using a simple example.
User A at Host A has agreed (by letter, telephone, etc.)
with User B at Host B for their respective processes to
establish a connection through the Network at a particular
time.  User B is to be waiting for the connection attempt
initiated by User A.  The issues to be faced are those of
addressing (how is User A to know to which socket to connect?),
and of security (how are both users to be confident that
they are talking each other, and not some interloper?).
     A fourth scheme follows which addresses another concept
of Network use--that connections are made between processes
and that processes not users should be identified via
Socket names.

FREELY SELECTED RANDOM SOCKET IDENTIFIERS (Scheme 1)

     Under this scheme a user is able to use any 32-bit
socket identifier he chooses.  Two restrictions apply:  the
least significant bit denotes the socket's gender (0-read,
1-write), and no more than one socket bearing a given iden-
tifier can be active at a host at a time.
     The two users select suitably random identifiers ("a"
and "b").  User A will attempt to activate his socket with
identifier "a" an connect it to socket "b" at Host B.  There
is the possibility that somebody other than User B has
activated socket "b" at Host B so that User A will address
the wrong  party.  However, the possibility that some other
user has accidentally picked this particular identifier is
reasonably small, since there are about a billion different
identifiers.  When the connection request from A gets to
User B, he examines the identifier of the calling socket.
If for some reasom it is not "a" or not from Host A, he
rejects the request, because it is likely to be from some