Keep Alive TCP/IP connected sockets over the Internet - when? how? and how much?

Question

UPDATE: Skip to the answer if you want to save yourself the lengthy preamble.

TCP/IP connections KeepAlives are specified to be at least once every two hours: https://www.rfc-editor.org/rfc/rfc1122#page-101. The problem is this was written in 1989 and is concerned about the cost of sending the extra KeepAlive packet! Yet it still is the default time most OS's in accordance with the spec send out KeepAlives down a connected socket after a period of inactivity! Of course nowadays most connections timeout way before that if inactive, and if connected to a peer over the Internet connections die without your knowledge way before that (despite setting ones timeout higher than that - I suspect because router tables in between don't bother keeping it alive - I always wondered where the leaked last message goes... UPDATE: The reason for this is 'routers' that may be at your or the remote hosts end are 'stateful' and connection aware and drop the connection after some period of time of inactivity - the routers that your go through over the Internet cannot drop your connection - they they dont care - the packet is just send where it has to go). So I have seen 2 common solutions to keeping ones connection alive over the Internet:

1. Disregard (EDIT: as has been pointed out to me this is not disregarding the spec it is just changing the default) the spec and change your system wide KeepAlive interval to lower than 2 hours, or 2) implement your own 'KeepAlive' system polling the peer periodically.

Either way; what is a suitable period (of inactivity at which to send your KeepAlive)? I have seen everything from 1 second to the default 2 hours. It seems the number is sucked out of thumbs... If I have a client application connecting from potentially anywhere in the world what is safe and reasonable period (I want a single persistent connection)? Connecting to a peer many hops away on the other side of the world over the Internet the connection dies on 301 seconds (though you only know about it when you try send something) so setting the period to 300 seconds seems to be the magic number - I get the KeepAlive 1 second before death - this interval has never failed me.. but is it safe?

EDIT: This particular connection im implementing in C# 3.0 so code in that welcome.

Answer 1

When

When you want to prevent you connection being dropped.

How

By sending something after a period of inactivity possible by either sending TCP/IP KeepAlives or sending something yourself (reccomended since setting the period at which TCP/IP KeepAlives are sent will apply at the system level to all connected sockets instead of at the application level).

How Much

How long is a piece of string? First you have to understand why the connection is dropped:

The reason the connection is dropped is:

Home/commercial "routers" and firewalls which are "stateful" and connection aware tend to drop external TCP connections after some period of inactivity

So it has nothing to do with your application or TCP/IP per se, but to do with the hardware or software your connection goes through. You could do some research into typical periods of inactivity at which home/commercial devices/software you may go through drop a connection (see lists below). However if the peer could be potentially any user on the Internet:

Ultimately if you cannot know what equipment/sofware they go through: allow for a client to set their own period of inactivity (at which to send something to keep the connection alive).

Or send KeepAlives (or your equivalent) at short intervals (of inactivity) to accommodate all cases (though unnecessary traffic is a bad thing an extra packet every few seconds of inactivity nowadays is a drop in the ocean, except mobile networks still). But be warned as per the specification on TCP/IP it is supposed to survive temporary outages so setting it too low could have the undesirable affect of not surviving a temporary outage, from http://aplawrence.com/Bofcusm/2426.html:

The down side of tightening the keepalive parameters is that you also sharply limit TCP's resilience in the face of cable outages. A session whose both ends are alive and ready to run normally stays alive even if an intermediate cable or router is disconnected for a few minutes. If you've told the server to frantically send keepalives, it will notice a cable break and disconnect sessions that would otherwise have survived nicely.

But you would have an outage if your was doing some comms anyway so you have to handle this and I think this concern is outdated as one does not get temporary outages (they are more likely to be permanent - cable unplugged) with todays persistent connections (as opposed to dodgy dial-up say). Should you have an outage you may want to re-establish your connection (such as RDP does) or not (such as Telnet).

Some research into what common applications use:

App    |    KeepAlive sent after    |    configurable    | ref
--------------------------------------------------------------
Telnet |    600 seconds             |          Y         | http://www-01.ibm.com/support/docview.wss?uid=nas14adccb91a24d9ed28625694900513857
MS RDP |    ?

And some research into what devices/software drop inactive connections and when:

Device/SW                |    dropped after    |    configurable    | ref
--------------------------------------------------------------
Windows 2003 Firewall    |    24 hours         |          ?         | http://technet.microsoft.com/en-us/library/cc755604(WS.10).aspx
SonicWall TZ100/200      |     5 mins          |          Y         |  http://www.sonicwall.com/downloads/SonicWALL_TZ_100_200_Series_Getting_Started_Guide.pdf
Netgear FR114P           |     5 mins          |          N         | http://www.broadbandreports.com/forum/remark,4182300
Cisco ASA                |     1 hour          |          Y         | http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/firewall/asa_91_firewall_config/conns_connlimits.html

Please edit to/refine these lists for the benefit of all.