by Darius Kazemi, May 9 2019
RFC-129 is titled “A Request for Comments on Socket Name Structure”. It's dated April 22nd, 1971, and it's authored by Harslem and Heafner of RAND, and Meyer of MIT's Project MAC.
The technical content
This RFC proposes two structures for socket names. Recall that a socket is a thing that the NCP can talk to, and the socket is connected to a process on the local host. The reason that you don't just connect to a process ID directly via the ARPANET is that process IDs can change. The idea is that the socket number remains constant throughout the duration of the connection and then the host itself can have a changing/arbitrary process ID behind the socket. This means the connecting host doesn't need to know about the internals of the remote computer.
The idea in this RFC is to propose more stringent limitations on what a socket number means.
There is already a convention that even sockets (where the least significant bit is a 0) are always receive sockets, and odd ones (LSB of 1) are send sockets. This RFC calls this the “gender” of a socket, which is a longstanding term that goes back, as many of these things do, to mechanical engineering terminology. And yeah it's basically because in actual mechanical device interfaces there is often a phallic looking thing going into a yonic looking thing.
Anyway, they set up this example that they're going to use to work through implications of the different socket naming conventions.
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?).
One thing I love about this is that it's explicit that so much of this involves calling someone by phone at a different university and saying “okay I'm going to connect to you now”. (This is not that different from when you're having trouble connecting to a video conference call today and you need to call someone on their telephone to make sure you're connecting to the right video call.)
Arbitrary socket numbers
First they discuss “arbitrary” socket values, where aside from “gender” there is not any intrinsic meaning to the number of a socket.
One way to approach socket names is that, “gender” of the socket aside, the users on either side can pick any number they want for their socket as long as it's not currently in use. They coordinate ahead of time so that user A knows to send a request to B on the correct socket, and that B is sure to be listening on the correct socket for a connection from the remote socket pre-determined by user A. This unfortunately can result in socket conflicts because, for example, the socket chosen by user B might, by the time they make the connection, be in use by someone else. Also it requires private out-of-band communication ahead of time.
Another way to approach arbitrary socket numbers is for the user to attempt a connection to host at a predetermined socket, which then routes them to a new arbitrary socket that they then connect to permanently. There is a proposed “Network Directory service” that handles this routing to sockets. The scheme is admittedly “rather cumbersome”.
Socket numbers with user IDs encoded
Another way to approach socket numbers is to effectively give each user a range of available sockets that they can access. This is accomplished by giving each user a permanent ID number on the local host and hard-coding that into the most significant bits of the socket number. The idea here is increased security – for example if sockets 256 through 512 are only accessible by User A on the local computer, then User B can be sure that a request from socket 294 is definitely coming from someone logged in as User A, and can immediately reject it if it is not from the expcted range. This removes any socket conflict between users, and is more secure. But it makes things more complex for the operating system and requires the NCP to understand more about what is happening in the OS.
No sockets at all
The authors also propose a socketless scheme, where processes simply connect to processes without the intermediary of sockets. This would require a special encoding system for process numbers though.