Network Working Group
Request for Comments: 129
Request for Comments: 129
22 April 1971
E. E. Harslem-Rand
J. F. Heafner-Rand
E. E. Harslem-Rand
J. F. Heafner-Rand
A REQUEST FOR COMMENTS ON
SOCKET NAME STRUCTURE
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 ]