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