Fix: The time-out for connecting to the content-server was shorter th… #8530
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.
Suggestion cannot be applied right now. Please check back later.
…an the combined timeouts for connecting to all resolve-addresses. So if connecting to the first N addresses timed out, OpenTTD would time-out the overall connection, even if one address finally succeeded.
Motivation / Problem
When OpenTTD starts a TCP connection, it tries all resolved addresses sequentially.
If network is broken, connecing can take quite some time.
The content client is intended to close its connection after 60s of no packets sent/received (inactivity). However, the timeout is started when starting the connection, not when finishing it.
So when connecting takes longer than 60s, the connection is closed immediately, without any packets sent at all.
Description
The timeout is reset, when a connection is established successfully.
Limitations
No parallel-connection pony for you.
Checklist for review
Some things are not automated, and forgotten often. This list is a reminder for the reviewers.