by Darius Kazemi, April 1 2019
Thinking about users
The technical content
The RFC begins with a problem statement: namely, that the network interface has thus far been treated like generic I/O. This is inconvenient when you have no idea what is on the other side of the I/O though, as different operating systems have wildly different underlying concepts. If you're talking to another computer running the same OS over the network then it makes things really really easy to treat the network as generic I/O, but not so much when there is a mismatch.
The author proposes a User-User protocol that sits on top of the Host-Host protocol. Where the Host-Host protocol deals in messages, the User-User protocol deals in logical records.
Our point of view is that a link is a carrier of information. Information is carried in segments of a fixed maximum length called messages. That this is so is an accident, from the user's point of view; when he wishes to transmit a contiguous stream of data, he will in general, segment it in a different (from the IMP-IMP or HOST-HOST protocol view) manner — we will call his segment a record.
Basically, the user cares to do something like “write a file to the remote computer”, whereas the Host-Host protocol only wants to know about a stream of segmented messages. Mealy wants a protocol that operates on a more “human” level but has interoperability between wildly different operating systems.
There follows a protocol description but I think the more important part of this RFC is the philosophical bit at the beginnging.
I think what Mealy is proposing here will eventually become FTP, the File Transfer Protocol. A file is a kind of logical record, and there was much effort put into FTP to make it into something that would work on all sorts of computers. In this 2014 interview with Bob Braden, he says
the IBM had a truly baroque file system, and we wanted to let customers have access to some of the features of it, whereas all the other systems were UNIX systems with a very simple file structure. So if you look at the FTP spec there’s some weirdness, complexity that’s there because I asked for it.
The “IBM” that he's referring to is the exact IBM computer that Mealy references in his intro to this RFC: the IBM 360. I don't think this is a coincidence. Mealy clearly wanted to be able to send files (or something like files) back and forth between a PDP-10 and an IBM 360.
Mealy writes in one of those collegial, casual, Feynman-esque academic styles. In some places his breezy style is really endearing.
ESC is intended as a (hopefully) unused escape hatch, for nonuse by those installations and/or applications wishing to avoid using more than four bits of the USER-USER protocol on any link. For instance, it may be desired to use a link as a bit stream, ignoring even message boundaries. If and when anarchists can achieve local agreement, more power to them!
The practical questions of implementation are something else! In the case of the PDP-10, I can pretty well see how to turn a SYS into either a LOGON request to execute a monitor command or UUO (would that they were the same) as the case might be. OS/360 is more sophisticated, unfortunately. MULTICS might make it. Naytheless, I hope that is clear that what we want to do, which is what the proto col should reflect, is quite a different question from that of how it is to be done in the context of a specific HOST system.
There is some casual sexism in this RFC, also recalling Feynman. Mealy proposes that bit flags in the protocol that are followed by data blocks be called “block flags”, and other flags be called “whyte flags”. The curious term “whyte” is footnoted as follows:
In memory of an attractive, but nonspelling, SDC secretary who could not distinguish between black and white, at least during 1957 and in manuscript form.
It's basically a bimbo joke. He could have left out “attractive” and this joke would have transitioned state from “creepy” to “mildly amusing”.
George H. Mealy invented the Mealy machine, which is not a literal machine but a mathematical construct called a “finite state machine”, which is basically a kind of algorithmic yes/no decision flow chart that a computer or even a physical machine can be constructed to make. Mealy machines are taught widely in electrical engineering programs (or at least they were in the 2000s when I last took an engineering class). For the nerds: it's a type of state machine where the current output is dependent on both the current state and the value of all its inputs. It's an “unsafe” machine where unless you latch your inputs you can change output mid-clock cycle and end up with some nasty edge cases.
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.