RFC 58

Logical Message Synchronization ✨

okay bestie, let's start with the title block 🎀. This is RFC 58, from the Network Working Group, written by T. P. Skinner of MIT Project MAC, dated June 1970. The original doesn't list a category, and it doesn't say it obsoletes or updates anything 🙈.

At the last network meeting, the whole logical vs. physical message thing came up 💅. Someone argued that you should never run two logical messages together as one or more physical messages. Another way to say it: a logical message must begin on a physical message boundary 🦋. But that still didn't solve how you find where a logical message ends 😭. Skinner's own rough idea was to use the first partial physical message as a sign that it was the last physical message of the logical message. That got thrown out for a bunch of very valid reasons 💀. What everyone liked most was putting a bit count or data type specification in front of the logical message 🧚, even though it was stated super generally.

Now it seems like people want to completely sever the link between physical and logical messages 🌈. Aesthetically iconic, ngl. But then the network is basically a virtually infinite bit stream with no physical delineations 🌸. Sending a logical header and bit count for each message works fine... as long as there are no errors along the line 💀. If a bit gets dropped, though, resyncing is a nightmare, because the only way to find the start of a logical message is brute force. You shift the message bit by bit and check whether the data looks reasonable 😭. That's time-consuming, and it opens the door to false synchronism. This kind of error could come from faulty host or user software/hardware, or from the imp itself.

I've got a few possible fixes, but none of them are great 🙈. First, when a user loses synchronism, they could send some form of error message to the other host. That host could stop sending and wait for a message to continue from the troubled user. This lets the troubled user flush out all waiting input, so they know the next bit starts a logical message. The catch is making sure everything stays in sync, because of input/output buffering in the network and at both hosts 💅. How can the troubled host be sure it has all the pending data? Once it's sure, it can resume input assuming all is OK.

Another partial fix needs the original restriction that logical messages always start on physical boundaries 🫶. Then a user only has to check the beginning of each physical message to see if it fits the pattern of a logical message header. That's way safer than examining the entire input stream, and quite a bit faster ✨.

I'm not trying to suggest a solution here, just bring the problem to light 🎀. If we want logical messages to begin on physical boundaries, we have to plan that early in the game. (It probably works out that way in most cases anyway 👑.) Other schemes can be tried later. But we have to face this problem fairly soon 🔥.

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Carl Alexander 7/97 ]