Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix: The time-out for connecting to the content-server was shorter th… #8530

Merged
merged 1 commit into from Jan 8, 2021

Conversation

frosch123
Copy link
Member

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

  • The bug fix is important enough to be backported? (label: 'backport requested')

…he connection has been established.

When connecting took long due to the first N resolve-addresses timing out, OpenTTD would immediately close the connection, without sending anything.
@frosch123 frosch123 merged commit 31d1968 into OpenTTD:master Jan 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants