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.