111

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?

Improve this question
3
  • 1
    Could this behavior also be implementation dependent? Is this something specified in the TCP standard, or is it left as an implementation detail? Hopefully someone else can answer that as well.
    – dss539
    Commented May 14, 2009 at 21:53
  • 1
    It's an implementation detail I would say as not all TCP/IP based protocols implement such it's left entirely up to you.
    – Lloyd
    Commented May 14, 2009 at 22:01
  • 6
    Yes - not becuase of TCP/IP - but because of other hardware or software you connection may go through such as firewalls and home 'routers' which tend to drop inactive TCP connections, related: stackoverflow.com/questions/3907537/…
    – markmnl
    Commented Mar 1, 2011 at 7:50

16 Answers 16

Reset to default
58

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.

Improve this answer
6
  • 42
    Another common reason for keepalives is o keep the connection open through nat gateways. While TCP itself doesn't need keepalives to operate, it's common for nat gateways to "drop" a tcp connection after a given timeout.
    – nos
    Commented Nov 30, 2009 at 23:48
  • 5
    What is a normal timeout? seconds, minutes, hours?
    – MiniGod
    Commented Jun 28, 2012 at 16:43
  • @Lloyd I "think" MiniGod meant, "How long would be a normal timeout?" (the answer given in seconds, minutes, hours, …)
    – jeromej
    Commented Jul 27, 2014 at 12:11
  • @JeromeJ Who knows, it's been a few years ;)
    – Lloyd
    Commented Jul 27, 2014 at 20:05
  • Also, if you connection is going through a proxy you can expect your connection to be dropped if considered stale. I don't think that keep alive would help in this case though, because this aspect of tcp doesn't propagate to the application.
    – Ghita
    Commented Aug 30, 2015 at 13:17
58

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.

Improve this answer
1
  • The TCP connection will say alive forever?
    – user7817808
    Commented Jun 14, 2017 at 18:26
26

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.

Improve this answer
1
  • 1
    This is networking generally, though. Consider Peter Deutsch's Fallacies of Distributed Computing; we know that networks are inherently unreliable, and so should be treated as an almost certain point of failure in your application. In this context, conventional wired network or not, assume you will experience failure at some point and design your application to handle that scenario.
    – Steven Bakhtiari
    Commented Jul 25, 2018 at 14:09
13

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.

Improve this answer
2
  • 1
    How is it suppose to work on linux? does it infact work? can i schedule the timeout to be less than 2 hours? for instance 30 seconds?
    – Itay Levin
    Commented Dec 26, 2012 at 13:17
  • For this to work the application needs to support keepalive. Just enabling it in Linux won't be sufficient.
    – Mike Vella
    Commented Oct 29, 2016 at 2:21
9

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.

Improve this answer
1
  • Keep alive can be implemented as a socket option SO_KEEPALIVE for individual connections. The interval between messages is 1 second by default. This may require support from both endpoints for correct operation.
    – Pekka
    Commented Mar 31, 2021 at 13:17
4

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

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

Improve this answer
4

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

Improve this answer
4

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:

  1. sockets level keep alive using OS settings or SO_KEEPALIVE option. This is transparent and will detect communication errors or broken partner systems promptly.
  2. 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.
  3. Application level keep alive messages that are sent and received to poll the partner for an active response.
  4. 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.

Improve this answer
3

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.

Improve this answer
2

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.

Improve this answer
2

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

Improve this answer
1

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.

Improve this answer
0
1

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

Improve this answer
1

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

Improve this answer
0

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

Improve this answer
-2

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

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.