22 April 1971
E. E. Harslem-Rand
J. F. Heafner-Rand
E. Meyer-MIT
E. E. Harslem-Rand
J. F. Heafner-Rand
E. Meyer-MIT
A REQUEST FOR COMMENTS ON
SOCKET NAME STRUCTURE
INTRODUCTION
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
reactions.
Please direct your replies via the standard RFC
mechanism.
Two structures are presented in this RFC as shown
below.
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.
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
HOST-SELECTED IDENTIFIERS PLUS DIRECTORY (Scheme 2)
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.
ADMINISTRATIVELY ASSIGNED USER IDENTIFIERS (Scheme 3)
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.
A VIEW OF SOCKET NAME MEANING (Scheme 4)
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 ]
-