Reputation: 3266

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?

Upvotes: 113

Answers (16)

Pekka

Reputation: 3654

TCP does not require keep alive messages to keep a session open. The protocol was intended for use on terminals and printers that could be active every few weeks without problems.

The transparent network-level elements that other answers identify can certainly cause unbelievable havoc to the extent of killing entire factories when they misbehave and lose sessions or otherwise interfere with the traffic. This is always incorrect and should not require any action by the application or OS developer.

If no keepalive is in place, a loss of communication error will only be detected on the next attempt to transmit.

There are three possible levels of keep alive:

sockets level keep alive using OS settings or SO_KEEPALIVE option. This is transparent and will detect communication errors or broken partner systems promptly.
Sending zero-length frames from the application will often provide a similar result. This will force a TCP PUSH and ACK segment pair that will detect a lost session.
Application level keep alive messages that are sent and received to poll the partner for an active response.
One party sends a heartbeat message periodically.

The first two result in no change in application-level information transmitted across the channel although they necessarily trigger the transmission of empty segments.

The last two options result in application communication and can provide more information. For example, if the host application has stalled and will not respond, then the first two alternatives cannot detect this failure mode. The fourth option works implicitly. The sender will receive an error eventually, and the receiver should expect periodic messages as an indication of a healthy session.

If higher level protocols are used - for example RPC or REST, then a Ping() function that returns something benign can be helpful.

Unless it is essential to detect the connection failures, it is often easier to simply reconnect when necessary. The choice depends on the application level protocol and end-to-end message guarantees from the requirements.

Upvotes: 4

Lloyd

Reputation: 29678

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.

Upvotes: 58

Eero Aaltonen

Reputation: 4425

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.

Upvotes: 26

Mayday

Reputation: 31

Basically a TCP connection creates link states stored in switches along to route. In order to detect broken connections (like when one counterpart crashes (without sending a proper disconnect)), these states have to be evicted after a period of inactivity. And when this happens, your TCP connection has been closed. Although I cannot exactly tell how long these timeouts are, they seem to depend on the device-producers and/or on internet providers. I remember my idle SSH terminal sessions were rapidly (less than 15min of idle time) closed by my former 1&1 internet provider while they stayed open for several hours when using a Kabel-BW provided connection...

Finally, I conclude with my previous speakers: a heart-beat is a good way to tell if a connection is still alive and kicking...

Upvotes: 2

Andrew Keith

Reputation: 7563

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.

Upvotes: 9

Vivek Sharma

Reputation: 3814

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.

Upvotes: 3

Unknown

Reputation: 46841

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.

Upvotes: 2

Gerald Combs

Reputation: 1412

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.

Upvotes: 59

Duck

Reputation: 27582

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

Upvotes: 4

Dark Star1

Reputation: 7413

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).

Upvotes: 1

D. Patrick

Reputation: 3022

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

Upvotes: 1

ist_lion

Reputation: 3209

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

Upvotes: -2

Brian Agnew

Reputation: 272437

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.

Upvotes: 13

ChrisW

Reputation: 56133

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

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

Upvotes: 4

anon

Reputation:

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

Upvotes: 0

Kekoa

Reputation: 28250

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.

Upvotes: 1

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

Answers (16)

Related Questions