Reputation: 23
There's a product (that will stay unnamed) that suffers from a peculiar feature/issue. It will drop new SYN packets if it is overloaded. This may not seem unreasonable to some. It may seem unthinkable to others. Be that as it may.
How many times will an upstream TCP client retry sending the SYN before giving up? Is this number based on a RFC or standard or is it just industry norm?
How about SCTP and INIT?
Upvotes: 2
Views: 4004
Reputation: 310988
The default TCP connect timeout, which is the underlying topic of your question, is platform-dependent at the client, somewhere around a minute. This is coded into the connect()
system call as 3 retries using timeouts of say 8,16,32 seconds, depending on the implementation. The TCP stack may do its own retries as well before failing back to the connect()
function, so there could be quite a few tries before the eventual ECONNTIMEOUT.
There is nothing wrong with a platform dropping SYN packets under overload. Unix has been doing it for thirty years, so it can't suddenly have become a problem now. It is a platform action, not a product action, so the secret unnamed product you mention is not the culprit, unless it is an operating system. I don't see why it can't be named here.
Upvotes: 2