tcp-ip@ucbvax.ARPA (07/27/85)
From: imagen!geof@su-shasta.ARPA TCP gives higher level protocols the responsibility of probing the foreign system. I believe that the higher level protocols divide up into the following three categories (this is in contrast to one comment recently made on the list): 1. Applications where the TCP connection is never idle. No problem. 2. Applications where the TCP connection is idle but monitored by a human user. Give the user a method to probe the connection (like telnet remote echo, or null probes), and you've solved the problem. Ultimately, every user has his or her own internal timer that says how long he/she is willing to wait. E.g., User FTP, User Telnet 3. Applicationes where the TCP connection is idle and are not monitored by a human user. Then the higher level protocol needs to send probes so that it doesn't hand forever. E.g.: SMTP, Server Telnet, Server FTP There is one point of commonality between 2 & 3: If a TCP connection is idle, it must always be possible for either side to send the other a probe. I have believed this point for some time. It is interesting that the rule is broken by the most obvious example of [3] -- SMTP. Between the time a User SMTP finishes sending a message (it sends the ".") and the time the server sends the response, the user is unable to send any data down the TCP connection, but must wait for the server. The TCP connection is idle, and TCP (as we all know by now) doesn't probe the connection. If the server crashes, the user is left hanging forever. The usual solution is a timeout. But there is wide variance in both the time that a system can tolerate a hung SMTP server and the time that it legitimately takes a slow server to process a message. So timeouts will always be causing certain messages/server combinations to reliably fail. Not quite what you wanted for a supposedly autonomous service. The real fix is an SMTP-level probe. The same problem is exhibited by XNS Courier, which requires that all XNS sequenced packet protocol implementations implement keep-alive probes (probes are permitted but not required by the spec). Beware if you implement Courier on top of TCP! - Geof
tcp-ip@ucbvax.ARPA (07/30/85)
From: geof@su-shasta.arpa Actually, a telnet SERVER is an example of an unmonitored network service. Class #3 was the number in my listing, I believe. I left it out of my examples because the telnet protocol has higher-level probing in the form of NOOP negotiations. Few telnet server programs actually exercise this option, though. Interpret my last message as a harangue at them and other server implementations of this class. When I see idle network connections on the system, I exercise them (and exorcise them) by sending a terminal message to the idle user which says "are you still there". The negative response is that the user's TCP connection times out (or -- usually -- gets reset) and the spurious login goes away. I guess a quick fix for a harried system administrator who doesn't want to hack code (or can't -- not everyone has sources these days) is to use /etc/cron to run a program once every hour or so that just sends a useless message to every network login. I guess that you could send a "^A" or something that would tend not to be visible, except for messing up an Emacs screen occasionally. - Geof