/ OpenTTD Public
Change: [Network] lower TCP connect() timeout to 3s #9112
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge.
CI will fail till #9116 lands and this is rebased.
Motivation / Problem
OpenTTD currently has the issue that if you have IPv4 and IPv6, but your IPv6 is broken (which happens more than we would like), you cannot really use the Content Service. It starts a connection to it over IPv6, wait till it fails, and tries IPv4 next. The problem: the timeout is 30s. And no sane user is going to look at an empty window for 30s in the hope something shows up :)
Additionally, in an upcoming PR we add STUN support. STUN is a bit of a trick, but basically it tries to connect a client and a server together via various of methods. Two of those are via
connect(). Having a 30s timeout there too means that is takes up to a minute before a fallback is tried that is very likely to succeed (but expensive for us in terms of cost). This means the timeout for STUN requests has to be reduced, as otherwise we will get a lot of reports :D
(edit: where I write 30s, it turns out it is this: 20s on Linux, 24s on Windows, and 75s on BSD / MacOS. Timeouts can never exceed that value, so 20s is the max, basically).
In this PR I purpose to change the default timeout to 3s, but we can tune it per TCP connection we want to setup. For example, I now also set the timeout to 3s for game servers, but we could leave that on 30s.
My reasoning why 3s is fine:
Arguments against it could be:
The main issue is and remains: 99% of the users connect far before any timeout, so it really is only a problem for a select few, on both sides of the isle. This isn't perfect, but neither is 30s, and anything in between. We can always up the limit if it turns out to be way too low for too many people.
Checklist for review
Some things are not automated, and forgotten often. This list is a reminder for the reviewers.