by Darius Kazemi, Jan 9 2019
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:
- Initial request by HOST X over link 0 to open a primary (command) connection to HOST Y via link 12
- HOST Y acknowledges the request and says “yup let's talk via link 12”
- HOST X send login data over link 12 to HOST Y, which sends back “yup, you can now send me commands”
- HOST X asks to communicate with a program on HOST Y, and data about this program will be sent over auxillary link 25
- files for that program are exchanged back and forth over link 25
- finally, HOST X communicates via link 0 that it is closing its connections on link 12 and link 25, freeing those up for other HOSTs
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.
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 “@firstname.lastname@example.org” and follow it there.