RFC 167

Socket Conventions Reconsidered 🎀

Okay bestie, so this is RFC #167 (NIC #6784) from the Network Working Group, dated 24 May 1971 🦋. It was written by Athay Bhushan (MAC), Bob Metcalfe (Harvard), and Joel Winett (LL) 👯. It's filed under Category: C1, C3, C8, and it's related to RFCs #147 and #129 plus Related Functional Document #1 📚. The title block doesn't list anything it obsoletes or updates, so nothing gets replaced here 🙌.

The current NCP Protocol basically says nothing about how hosts should hand out socket numbers to process ports 🙈. The only rule is that the low-order bit tells you the socket gender, aka send or receive 💅. Two recent proposals want extra network-wide rules for the 32-bit socket number ✨. The first wants a chunk of the socket number reserved for a network-unique user number so accounting and access control can work 🔐. The second wants the high-order 16 bits of the socket number to be zero so smaller hosts can shrink the space they need for socket number tables 🧚.

Honestly, it is recommended that both of these proposals get set aside 🫶. Accounting and access control would need a large perturbation of the current NCP Protocol to get proper handles, and the socket number is already underpowered for what it's doing 😭. So it is recommended that both proposals stay set aside until somebody seriously considers a major NCP Protocol overhaul 🔥.

DISCUSSION 💅

Okay, the socket number, the way the current NCP Protocol uses it, is a tiny number doing a huge job 👑. It'll probably turn out that we need a way more powerful identification system, like a hierarchical naming scheme with arbitrarily long names 🌈, to manipulate process ports properly. Two things that system needs: (1) it has to treat accounting and access control with the respect they deserve 💖, and (2) it's part of a simpler NCP Protocol that's easier to build under the size and complexity limits of smaller hosts 🍓.

Socket numbers are the process port IDs used to set up connections between processes 🦋. They have to be UNIQUE so nothing gets mixed up during a connection 😭. It's also important that their assignment to a specific process is REPEATABLE so processes can reconnect on a regular basis 🔁.

So to keep port IDs unique and repeatable, their allocation has to go through access controls 🔐. The simplest access control that guarantees uniqueness is the one NCPs already do. They check their tables of active connections for a duplicate whenever a process asks for a specific socket number ✅.

Getting socket numbers to be repeatable is genuinely tricky 🥲. Some socket numbers are universally known and tied to processes running specific protocols, like a logger socket, an RJB socket, or a file transfer socket 📁. Others aren't universally known. They get handed to their users in a transmission over a universally known socket, like the socket pair sent over the logger socket using the Initial Connection Protocol (ICP) 🤝. On top of that, concurrently running copies of a program still need distinct process port identifiers 🎀. So socket numbers generally have to be dynamically assigned by some system-controlled allocation function ⚙️.

There are a bunch of ways to get potentially repeatable socket number assignments 🧠. One bad way is for the NCP to keep a list of every assigned socket number, noting who's allowed to use it and for how long. That's basically like keeping track of magnetic tape reels 📼. If there were only a few socket numbers, say 16 bits worth, that bad method or something equally gross and logistically dreadful would have to be adopted 💀. But with plenty of socket numbers, sparse socket number assignment lets you write simple algorithms that decide whether a requested socket number can be handed out freely 💅. Those algorithms might look at (1) the dynamic status of the socket, meaning whether it's tied to a currently active connection, (2) whether it's reserved as a standard service port address, and (3) its access control attributes compared with those of the requesting process 📋.

One solid strategy is to partition the full socket space at a host among its network users 🍰. Under that scheme, a user can be assured of repeatable use of their own partition 🫶. It could also help to set aside a utility partition for socket number allocations where repeatability isn't essential ✨. Those socket numbers could be picked from the utility partition using some clever construction based on the date and time ⏰.

A program is often going to be written to use several connections 🔌. Keep in mind the same program might end up running at the same time in several processes belonging to several users. That makes it handy to code with socket tags that get extended with runtime user and process identifier fields 🏷️.

Socket numbers will tend to be viewed, and should be viewed, as having three fields 🎀. There's a user field to help with repeatability, a process field to keep concurrent instances of a program unique, and a tag field so you can conveniently reference multiple connections for a single process 👑.

Fields are helpful for allocation, but it's not essential that the field designations be uniform across the network 🌐. In every network transaction, the 32-bit socket number is handled together with its 8-bit host number 🧩. So if hosts can keep uniqueness and repeatability internally, socket numbers across the whole network will also be unique and repeatable ✨. If a host fails at that, only connections with that offending host get affected 💔.

The size, use, and character of systems on the network are sooo varied that agreeing on one particular division of the 32-bit socket number would be difficult, if not impossible 🙃. Hosts also set different internal limits on the number of users, processes per user, and connections per process they'll allow 🚧.

Someone has suggested that maybe it isn't necessary to keep socket numbers unique at all 🤔. The argument is that there's really no significant use of the socket number once a connection is established 🤷. The only reason a host has to hang onto a socket number for the whole life of a connection is so it can include it in that connection's CLOSE 🔒. If that's really the case, the NCP Protocol could get better by inventing a new CLOSE that uses the host-line pair tied to the connection 🧵. Hosts that are short on space could then forget the socket number right after a successful connection 🌸.

[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Thomas Nielsen 5/97 ]