Socket heartbeat vs keepalive

Question

What are pros and cons for implementing own heartbeat and setting`keepalive for a socket?

I read somewhere, that keepalive sometimes can fail and connection will be closed anyway (depends on network structure). Another thing is that own heartbeat can detect if application is responsive (not only the socket).

My main goal is to ensure all of these: keep connection alive, even though no data is send (beside possible heartbeat), fast connection loss detection on both sides, application responsiveness detection.

I have already implemented a simple heartbeat on two ends and it works great, however I wonder if maybe I could replace it with out of the box keepalive feature.

Answer 1

One problem with TCP's built in keepalive feature is that it's not always easily configurable. For example, on Linux there are various options to setsockopt() (e.g. TCP_KEEPIDLE, TCP_KEEPCNT, and TCP_KEEPINTVL) that you can use to set the keepalive's behavior to what you want, but in other OS's those behaviors are not easily adjusted, at least not programmatically. So if you want your program's keepalive behavior to be portable to various OS's and behave consistently on all of them, rolling your own heartbeat is generally the way to go.

On the other hand, there may be some programs or network protocols out there that don't easily support the concept of a heartbeat/no-op message (or you might want your program to be able to use many protocols, without having to come up with separate keepalive logic for every supported protocol), and in that case you might want to use the built-in keepalive because it has the ability to send and receive "transparent" keepalive packets that do not affect the contents of the TCP data stream. In that case, the built-in keepalive can be useful (especially if you only really need the keepalive code to work under Linux).