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

Question

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?

Answer 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 it's ping for example.

Answer 2

What you call a heartbeat is useful when trying to set timeouts. Your socket may appear open, but the person on the other end may be suffering a BSOD. One of the easiest ways to detect defunct clients/servers is to set a timeout and make sure a message is received every so often.

Some people call them NOOPs(No Ops).

But no, they are not necessary to keep connection alive, only helpful to know what the status is.

Answer 3

The connection will remain open - there is no need to implement a heartbeat, and most applications that use sockets do not do so.

Answer 4

Are heartbeats necessary to keep a TCP/IP connection alive?

They're useful for detecting when a connection has died.

Answer 5

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.

Answer 6

A lot of protocols implement a heartbeat or a health status type of thing like Lloyd said. Just so you know the connection is still open and if you may have missed anything

Answer 7

I would say that if you don't have a heartbeat, it doesn't matter if your TCP/IP connection is open or not.

Answer 8

Heartbeat isn't a necessity for TCP protocols. It's implementation is there to detect whether the otherside has terminated the connection in the non standard way (i.e not gone through the tear down process).

Answer 9

TCP will keep the connection alive. The application heartbeats are for application level considerations like failover, load balancing, or alerting administrators to potential problems.

Answer 10

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.

Answer 11

TCP/IP as a protocol is specified as not being closed until you send a close packet. I have had sockets remain open even after having spotty wireless or internet connections.

However, this is all very dependent on implementations. Most likely there will be a "timeout" which means the maximum amount of time to wait for a response before considering the connection to be "dead". Sometimes this is based on the application itself, sometimes on NAT routers.

Therefore, I would highly recommend you keep a "heartbeat" to detect bad connections and keep them open.

Answer 12

The heart beat is a good way to tell the server that you are alive, whereby i mean that, if server is using DoS attack prevention systems, it (the server) may remove all the allocated resources for that particular connection, after the it detected in-activity for a specified period.
Their no mandate to implement any heartbeat mechanisms.

But its is good if you are designing an application, where the main criteria is responsiveness. You will not like to waste time on connection setups, DNS lookups, and path-discoveries. There just keep a connection up all the time, keep sending heartbeats, and the application knows connection is alive, and connection-setup is not required. Just simple send and receive.

Answer 13

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.