RFC-129

by Darius Kazemi, May 9 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

Socket names

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.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm an independent technologist and artist. I do a lot of work on the decentralized web with both ActivityPub and the Dat Project. You can support my work via my Patreon.