4 ms·

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 som

by klabb3 3y ago

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?

suprjami 3y ago
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 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.
- klabb3 3y ago
  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.
  - suprjami 3y ago
    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.
bewo001 3y ago
From my VoIP experience, there is no 'typical' in NAT. There have been attempts to classify NATs (https://www.rfc-editor.org/rfc/rfc3489 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 https://www.rfc-editor.org/rfc/rfc4787, Section 3). So, yes, application-level keepalives are your best bet.

by klabb3 3y ago

suprjami 3y ago

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

klabb3 3y ago
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.
- suprjami 3y ago
  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.

bewo001 3y ago

From my VoIP experience, there is no 'typical' in NAT. There have been attempts to classify NATs (https://www.rfc-editor.org/rfc/rfc3489 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 https://www.rfc-editor.org/rfc/rfc4787, Section 3). So, yes, application-level keepalives are your best bet.