[Other] Why can't tcp keep-alive be used instead of heartbeat?

[MakarMS]

Hey, all. What is the big benefit of heartbeats instead of the usual tcp keepalive?

[lukebakken]

You yourself commented here and then, it appears, deleted your comment.

@michaelklishin's comment is still relevant:

php-amqplib/php-amqplib#461 (comment)

---

TCP keepalive's goal is to maintain a TCP connection for a long as possible, assuming issues are transient.

Heartbeats' goal is to detect peer unavailability as soon as possible, because with TCP keepalive and default Linux settings it can take over 30 minutes by default (yes, 30 minutes).

[MakarMS]

But keep-alive can also detect it. There is nothing stopping you from setting the required interval, number of attempts on a socket and delegating this to the kernel via setsockopt() and not relying on the default kernel settings

[MakarMS]

Essentially any transport protocol has a state detection mechanism built into it that can be relied upon

[michaelklishin]

@MakarMS if you understand the limitations of TCP keepalives and think that you know better than the authors of every messaging and streaming protocol out there, use TCP keepalives. It is mentioned in our docs. We will continue recommending and enabling heartbeats by default.

I fail to see how this discussion has any practical benefit to RabbitMQ.

[michaelklishin]

The Heartbeats guide explains when TCP Keepalives can be used.

Not every system can rely on them, and TCP in general tries hard to redeliver data, not help you detect failed connections quickly, so messaging and streaming protocols introduce heartbeats under this or other names.