Is application level heartbeating preferable to TCP keepalives?

Question

Is there a reason why I should use application level heartbeating instead of TCP keepalives to detect stale connections, given that only Windows and Linux machines are involved in our setup?

Waterspout

Not sure what you're asking, more info? – Suellensuelo

How do you detect that a connection has gone stale? Meaning, it is no longer connected to the other end (but without a RST packet having been received). The ZeroMQ documentation details application level tricks to overcome this problem, but I don't understand why setting the TCP keepalive options on the socket level isn't enough. – Asti

Answer 1

It seems that the TCP keepalive parameters can't be set on a per-socket basis on Windows or OSX, that's why.

Edit: All parameters except the number of keepalive retransmissions can in fact be set on Windows (2000 onwards) too: http://msdn.microsoft.com/en-us/library/windows/desktop/dd877220%28v=vs.85%29.aspx

I was trying to do this with zeromq, but it just seems that zeromq does not support this on Windows?

Waterspout

Answer 2

From John Jefferies response : ZMQ Pattern Dealer/Router HeartBeating

"Heartbeating isn't necessary to keep the connection alive (there is a ZMQ_TCP_KEEPALIVE socket option for TCP sockets). Instead, heartbeating is required for both sides to know that the other side is still active. If either side does detect that the other is inactive, it can take alternative action."

Oscoumbrian

Answer 3

TCP keepalives serve an entirely different function from application level heartbeating. A keepalive does just that, it keeps the TCP session active rather than allow it to time out after long periods of silence. This is important and good, and (if appropriate) you should use it in your application. But a TCP session dying due to inactivity is only one way that the connection can be severed between a pair of ZMQ sockets. One endpoint could lose power for 90 minutes and be offline, TCP keepalives wouldn't do squat for you in that scenario.

Application level heartbeating is not intended to keep the TCP session active, expecting you to rely on keepalives for that function if possible. Heartbeating is there to tell your application that the connection is in fact still active and the peer socket is still functioning properly. This would tell you that your peer is unavailable so you can behave appropriately, by caching messages, throwing an exception, sending an alert, etc etc etc.

In short:

• a TCP keepalive is intended to keep the connection alive (but doesn't protect against all disconnection scenarios)
• an app-level heartbeat is intended to tell your application if the connection is alive

Juvenile

I would like to disagree. You say that that if an endpoint loses power for 90 minutes, TCP keepalives wouldn't do squat? How would that be, since the offline endpoint would no longer respond to TCP keepalives and the connection would be deemed dead. This is exactly the scenario I used TCP keepalives for, and it worked perfectly. – Asti

You forced me to do some reading - I've only ever used keepalive to avoid an idle timeout, but saw that it is intended to actually provide info of disconnects if they occur as well. That said, the answer remains that ZMQ does not use this feature of TCP keepalives, and does not provide your application with disconnect event data, and so it's reduced to only performing it's role of preventing idleness. This is a conscious decision on the part of the designers, their reasoning boils down to one goal of their abstraction being to make disconnects and reconnects more seemless. – Juvenile

Yes, the underlying TCP connection would die but the ømq stream would stay connected. That is precisely what I was after here. However, ømq 4.0 provides a way for the application to detect transport level disconnects and react to them. Some protocols like IRC implement protocol level heartbeating instead of using TCP keepalives. This has mystified me for some time. – Asti