Network Working Group
Request for Comments: 129
NIC 5845
22 April 1971
E. E. Harslem-Rand
J. F. Heafner-Rand
E. Meyer-MIT




     This RFC is in answer to a request (made at the
February NWG Meeting at the University of Illinois) that
we comment on several suggested socket name structures.
We apologize for the delay in getting out these comments
and we hope that you will respond more quickly with your
     Please direct your replies via the standard RFC
     Two structures are presented in this RFC as shown

                        31                 1
     1.   |         Arbitrary             | | <-- gender

                        24             7   1
     2.   |        User ID         | tag  | | <-- gender

     Three variations are given for the way in which
socket names are assigned, as examples of use of the
first structure.
     1.   Users pick the arbitrary number arbitrarily
          and associate it with a process.
     2.   A logger chooses the arbitrary number dynamically
          and associates it with a process via a directory.
     3.   The arbitrary number is assigned outside of a
          logger but may be issued by a logger to the
          remote party.


     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


     This system uses the same socket identifier structure
as presented above, except that the Host picks the identi-
fier at the time the socket is assigned, and the user has no
no prior knowledge or control of the assignment.  By itself,
this system would be totally unusable, because there would
be no way for User A to address User B.  However, it allows
certain service functions (such as the Network logger) to
have specifically assigned sockets.
     One of these is a Network Directory service.  This
serves to relate a socket identifier at a particular host
to the name of the user operating it.  This might either
be a single distributed service, or there might be a separ-
ate service at each host.
     Under this scheme, each user, A and B, first activates
his socket (or somehow gets his host to assign and tell
him of a socket identifier).  Then he gets the Directory
module at his host to associate his name with the identi-
fier of the socket just activated.  Following this, User A
in some manner gets the Directory Service at Host B to tell
him the socket identifier assigned to User B.  Then User A
dispatches a connection request for this socket.


     This is the system that is put forth on page 5 of
Protocol Document 1(8/3/70).  Under it a user is permanently
assigned a user identifier by his home host.  There is a
user identifier subfield within the socket identifier, and a
user is permitted by an NCP to operate only those sockets
bearing his uder identifier.  This gives the user a selec-
tion of 256 sockets operable by him.
     In arranging for the connection the two Users A and B
tell each other their user identifiers (alternatively a user
ID could be read from a directory), and User B specifies
which of his sockets ("b") that he will "listen" on.  At
connection time, User A selects one of his sockets and
requests connection for it to socket "b" specified by User B.
By protocol only User B can operate socket "b", so User A
can be certain of reaching the right party.
     When User B receives the connection request, he examines
the user identifier subfield of the calling socket identifier.
If it is the user identifier of User A, User B accepts the
connection request, confident that it is actually User A at
the other end.  Otherwise B rejects the request.


     Another view of Network use is that programs will con-
nect to programs, via NCPs.  Some of these programs may be
multi-access subsystems that are really agents for local
consoles (and TELNETs).  Consoles will generally communicate
through some such software agent rather than directly to
an NCP.
     Programs, then, must have a fixed, unique identifier,
known to its remote users and perhaps to its local logger.
The identifier is constant; it does not change from day to
day.  If such a program is to allow multiple concurrent
connections (for many or a single user) then it must have
a range of variable identifiers as well.  It makes sense
to group these sockets in a contiguous range.  The variable
identifiers are transient and are dynamically associated
with Network logical connections.

      +---------------------   ---------------------+
      |                                           |
      | Fixed, unique       /  /  Variable          |
      | Identifier         /  /  Identifier         |
      |                                           |
      +---------------------   ---------------------+

      _________  _________/   _________  _________/
                /                       /
       Identifies the           Identifies a particular
       program uniquely         connection of the program
                24                   7     1
       | Program Number         |Multiplex| | <-- Gender
       |                        |  Code   | |

     The Socket name structure #1 (page 1) thus accomodates
the above example as well as other exploratory socket name
structures and various "standards" superimposed on the arbi-
trary field.

[ This RFC was put into machine readable form for entry ]

[ into the online RFC archives by Simone Demmel 4/97 ]