Browse Prior Art Database

Request for comments on socket name structure (RFC0129) Disclosure Number: IPCOM000002109D
Original Publication Date: 1971-Apr-01
Included in the Prior Art Database: 2019-Feb-10
Document File: 6 page(s) / 8K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

E. Harslem: AUTHOR [+2]

Related Documents

10.17487/RFC0129: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 32% of the total text.

Network Working Group 22 April 1971 Request for Comments: 129 E. E. Harslem-Rand NIC 5845 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 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.

[Page 1]

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.


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 rea...