by Darius Kazemi, May 22 2019
RFC-142 is titled “Time-out Mechanism in the Host-Host Protocol”. It's authored by Charley Kline and Johnny Wong of UCLA and dated May 3rd, 1971.
The technical content
The issue at hand here is related to an error case not specified in the Host-Host protocol. Namely: what happens when no messages are sent over the connection for a long time? In other words, what happens when the connection stalls for some reason? That's qualitatively different from an error message.
They suggest the following algorithm.
- if you request a connection and don't get anything back from the remote host in T seconds (standard across the whole network), then you should send out the “close connection” command
- if you don't get acknowledgment of the “close connection” command you just sent within T seconds of sending it, then you should assume the connection closed
The problem here is that if you assume the connection is closed, then you reconnect on the same socket, and then you get a response from the server for some very old message you sent in the previous session, then that is a confusing situation. There's no way to truly know if this new response is related to the old session or the new session. The authors are merely bringing this confusing situation to light and asking people for ideas for solving it.
My suggested solution is: don't reconnect on the same (local) socket after you close a connection. This would prevent this weird race condition from happening in the first place.
Hopefully we will see the answer to this in a future RFC.
This is the first RFC authored by Charley Kline, who was apparently the person who sent the first message over the ARPANET. Here is an All Things Considered interview with Kline about that message and ARPANET in general.
I have more information about Johnny Wong in my RFC-117 post.