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

Rewritten Master Server in Python #1

Merged
merged 13 commits into from Sep 6, 2020

Conversation

TrueBrain
Copy link
Member

Contains both the server handling the ingame actions (client and server) as a web-api.

@TrueBrain TrueBrain force-pushed the initial_version branch 3 times, most recently from d662f17 to 53ee7bf Compare September 5, 2020 16:40
frosch123
frosch123 previously approved these changes Sep 6, 2020
.flake8 Outdated Show resolved Hide resolved
The token is used to avoid people sniffing session-keys of other
servers. Without this, a bit of guessing can get you very lucky.
With this, you also have to guess a 1 in 256 value right. This is
unlikely.

The session-key now also uses the current time in the key. This
helps mitigate the above issue even further, as you now also have
to guess the time of the server correctly. Although this is more
likely for you to have right, it is at least better than having
a fixed value to use.
In the current OpenTTD implementation, all IPs send a register
packet to the master-server. When the client just started, this
is zero for all of them. This means the master-server cannot
detect this was from the same server.

By sending back a session-key to use, and waiting for the server
to use this, multiple IPs do end up with the same server.
For example, OpenTTD can send an unregister without register in
some odd cases. Or due to race-conditions in OpenTTD it can
register the server with two different session-keys on two
different IPs (IPv4 / IPv6 for example). This last case is very
unlikely to happen, but we protect against it anyway.
…ifferent things

We want to validate if people are guessing the token; for this you
first need to know if you know the session-key. After thatn you need
to validate if the token in the session-key is correct.
Don't auto-detect if a packet is a PROXY-protocol packet; that
can result in people faking their IP. Instead, only enable
PROXY-protocol if it is set as argument to do so, and after that
expect all packets to be PROXY-protocol packets. It is now up
to the system administrator to ensure no other network path exists
where a user can call the server without PROXY-protocol.
Additionally, we are going to drop "updater", and only query a
server every 15 minutes (instead of every 5 minutes) when ever
they re-advertise their server. This is sufficient for now, and
heavily reduces the complexity of the master server.
It caches the server-list for 30 seconds, as fetching all servers
from the database every time is pretty expensive in both costs
as latency.
There are two endpoints:
/server -> shows all the online servers including all their meta-data
/server/<server-id> -> shows information about the server, if it is still known
                       (can be online / offline).

<server-id> is the md5() of the IP + port of any of the IP/port
combos of a server. If the server has a dynamic IP, this will
constantly change. The server-id is only to lookup information
about a specific server with this API, and has no further purpose.
Information per server is only changing every 15 minutes, so caching
it for this long is fine.
For server-listing, 5 minutes can be a bit long, as it means that
new servers takes 5 minutes to show up in the API. But as the API
is for information-only, and not really used to connect to servers,
this is fine.

The benefit of caching it for 5 minutes, is that the DB is under
less load from the API, and people hammering the API won't have
any effect on the database. As it is easier / cheaper to scale
up the API, this is the best solution.
@TrueBrain TrueBrain merged commit c13842c into OpenTTD:master Sep 6, 2020
@TrueBrain TrueBrain deleted the initial_version branch September 6, 2020 19:25
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