by Darius Kazemi, Jan 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.

Host software, take 3

RFC-9 is, like RFC-8, a scan of a document rather than a transcription. It is also authored by Gérard Deloche. Mercifully, this one is typewritten rather than handwritten. It's dated May 1, four days earlier than RFC-8. It seems to be a more formal document and it refers to itself as a “paper” although I'm not sure if it's a reprint of a paper that was published elsewhere (like RFC-5 was). It shares its title, “Host Software”, with RFCs 1 and 2. It covers the same material and like RFC-8 seems to be a kind of synthesis document, though with some crucial differences.

The technical content

Up until this RFC we have consistently heard that there are 32 links (bidirectional data channels) between HOSTs (link 0 used for control and links 1 through 31 used to transfer data). This paper suddenly claims there are 256 links between HOSTs, though 0 is still the control link. I'm not sure what changed here, or if this is simply a proposal and was never implemented. I skimmed future RFCs as well as BB&N IMP reports and a formal paper on the Network Control Center operations from 1972 and couldn't find anything concrete on the number of links. (Interestingly “links” seems to be a Network Working Group term while BB&N refers to “data lines”, which is in my opinion a clearer term for what these things actually are.)

Apparently the IMP network couldn't handle more than 64 simultaneous connections! Or at least this is the assumption as of May 1 1969. Remember no actual messages were sent until October so things could change by then.

Section 2.2.2 combined with Figure 3 in the document provide the most specific example yet of what two HOSTs talking to each other over the network would look like. The specifics are worth reading in the PDF of the RFC itself but the example goes through:

The paper also describes data structures in detail. An individual HOST keeps a “host table” which is basically N rows and 256 columns per row. The columns represent the 256 links possible and so if HOST 3 is using 4 different links on the network, the row for HOST 3 will have 4 different columns with a 1, the rest 0. The document notes that the table should never have more than 64 1s at any given time, because otherwise the network would be overloaded. I think the idea was for the HOST machines to keep track of this and then not attempt to open more connections if it knew there were already 64 in use.

The HOST also has a “link table”, with one row per established link containing detailed information about said link like the link's current status and what local user is monopolizing the link. This may also contain information about remote links but it's unclear to me from the document how this information is passed back from a remote host. (I know from reading ahead to RFC-11 that this table wouldn't know about any links that don't involve the local HOST.) There is also a “user table” that contains information about specific users, specifically for a given user, how many links they have open at a given time and what the ID of those links are.


I'm left scratching my head over a lot of things implied but never stated outright by this document. Fortunately RFC-11 will expand upon this greatly — it's basically this 15 page paper but with three more months of work put into the details, and expanded to 54 pages. But we'll get there in two more days.

Further reading

Nothing this time.

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 a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.