Hacker News Reader

Comment by klabb3 | Hacker News Reader

In practice, I’ve noticed keep-alives are unreliable especially for shorter timeouts on say websockets where you need a bit tighter intervals. Every OS does something different and usually the timeouts you get are quite long (and unknown to the application layer iirc - an opaque mix of os level knobs/multipliers and per-socket options).

Afaik current best practice is to reimplement application level keepalives everywhere. But it seems to me like both protocol pollution and prone to subtle leak-like bugs for dead conns. It would be nice if keep-alives could be used instead.

Also: NATs and firewalls put timeouts in their “routing tables”(?) so that conns are dead after X seconds anyway. Does anyone here know from experience what X is typically, in practice?

View on HN

Linux has socket options which let socket owners query and set TCP Keepalive parameters. See `TCP_KEEPCNT` and friends: https://www.man7.org/linux/man-pages/man7/tcp.7.html

The usual term for the table is NAT table or connection tracking table.

The usual timeout is as long as a piece of string.

I've seen timeouts as short as a few seconds. These are sometimes configured in environments where applications are expected to pause for longer than a few seconds, so the software reports a timeout on many actions.

I've also seen timeouts hours long. These are sometimes configured in environments where tuples are reused rapidly so the NAT device drops new connections which land on the same tuple because those connections are "old".

Networking is great.

Thanks for this.

> See `TCP_KEEPCNT` and friends

Yeah, 3 options with manually tuning even the number of probes. And this is for one OS only. This is one reason why application level pinging is just more feasible. I am using Go and gave up on tcp keepalives (even though they do have an std api) because the resulting behavior was a mess.

I don’t know if it should be the job of stdlibs or the OS, but at application level I’d prefer something like a single keepalive param with reasonable behavior.

Yeah, what you say makes sense. I am sure you are not the first person to think of this. I wonder if a pre-made library exists for it? I couldn't find anything with a quick search.

From my VoIP experience, there is no 'typical' in NAT. There have been attempts to classify NATs (https://www.rfc-editor.org/rfc/rfc3489, Section 5), but they have been abandoned after seeing how NATs sometimes change their behaviour dependent on their load, the number of connections, the phase of the moon etc (https://www.rfc-editor.org/rfc/rfc4787, Section 3). So, yes, application-level keepalives are your best bet.

Reply on news.ycombinator.com