Do I need to heartbeat to keep a TCP connection open?

I have two components that that communicate via TCP/IP. Component A acts as a server/listener and Component B is the client. The two should communicate as quickly as possible. There can only ever be one connection at any time (though that is aside to this question). A senior developer at my company has said I need to use application level heartbeats between the two components to ensure the connection stays open.

I thought the connection stays open with TCP/IP but I've read a number of blogs/sites saying it's pretty standard practice to heartbeat between these applications.

I know part of the reason component A heartbeats component B is so it can inform support if there are communications problems with component B (either the link is down or component B is not running). Are heartbeats needed for any other reason? Such as to ensure there is frequently something "in the pipe" to keep it open?

Component A currently heartbeats component B every 20 seconds and closes the connection if nothing is received back from component B in 120 seconds. It then resumes listening for connections under the assumption that component B will periodically try a reconnect if the link is broken. This works successfully.

To reiterate my question: Are heartbeats necessary to keep a TCP/IP connection alive?


Solution 1:

The connection should remain open regardless but yes it's often common to see protocols implement a heartbeat in order to help detect dead connections, IRC with the PING command for example.

Solution 2:

As many others have noted, the TCP connection will stay up if left to its own devices. However, if you have a device in the middle of the connection that tracks its state (such as a firewall), you may need keepalives in order to keep the state table entry from expiring.

Solution 3:

If your components:

  • are in a conventional wired network
  • there are no firewalls or NAT routers between them
  • neither of them crash

then you do not need to have a heartbeat.

If any of these assumptions are false (I am looking at you, GPRS!), a heartbeat becomes necessary rather quickly.

Solution 4:

You don't need to send heartbeats yourself. The TCP connection will remain open regardless of usage.

Note that TCP implements an optional keepalive mechanism, which can be used to identify a closed connection in a timely fashion, rather than requiring you to send data at some later date and only then discover the connection is closed.

Solution 5:

If your using windows, be cautious about the TCP Keep-alive. By default, its disabled unless you either turn it on globally with the windows registry or via setsockopt.

The default keep-alive interval is 2 hours.

http://msdn.microsoft.com/en-us/library/ms819735.aspx

You might need to implement your own heart beat and disable TCP keep-alive on windows if the 2 hour keep-alive alive is not desirable.