jas@proteon.com (John A. Shriver) (05/30/89)
I can detect loss of connectivity real easily. Just type a character. If the connection won't work, it will time out, or get an immediate TCP reset. However, I have no desire to watch my Telnet windows just go *pop* just because there was a lack of connectivity for thirty seconds. This happens quite often in the real world, like when one route goes away, and the routing protocols have to re-settle. In the interim, the keepalives will cause ICMP error messages to be sent (which routers *must* send to meet RFC 1009), and the connection will be gratuitously shot. Keep-alives are, from my point of view, keep-deads. They guaruntee that the my connection *will die* any time there is any momentary network outage. Keep-alives are absolutely contrary to the robustness principle. (See TCP RFC.) In my experience, keep-alives kill far more live connections than dead ones. If we're going to retain the stupid idea of keep-alives, lets add a session protocol to TCP-IP to put the connection back together after the keep-alive kills it. However, since I doubt many people want to add a session protocol to TCP, I'd rather kill keep-alives. Let's quit trying to bend over backwards to make the TCP/IP specs match the 4.xBSD implementations. They were experimental, and not fully conformant to the specs. They were optimized for a local network, not an Internet. The specs work, lets meet them. Fix the code. If you want the server Telnet host to be able to clean up your connection, many systems have inactivity timers, which can kill it for you. Please don't break our TCP protocol because of a limitation in some other operating system.