You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I start a server with dualstack (IPv4 + IPv6), I expect a single masterserver registration with both IPs.
Actual result
The first time, I register two servers: one for IPv4, and one for IPv6. Only when the second announcement happens, they are collapsed into a single entry.
Steps to reproduce
Start a cleanly installed OpenTTD server. Your server will briefly (well, for the next 15 minutes) show up as 2 servers on the serverlist.
What is going wrong?
When a server registers to the master server, initial he does this without a session_key (well, it is set to zero). In response, the masterserver will send back a unique session_key to track this server. The idea behind it is that the server can announce on multiple IPs; as long as the session_key is unique the masterserver knows that this is the same server with multiple IPs.
The server runs registration async; and you can guess now what happens. On the first run, both the IPv4 and IPv6 announce with a session_key of zero, indicating the masterserver should allocate one. He does so, two unique session_keys, because the masterserver has no clue this is in fact the same server. In result, two servers show up instead of one.
When the re-announcement happens, 15 minutes later, the game did settle on either one of the session_key. From this point on, the masterserver collapses the two entries into one, and all is well again.
Suggested fix
When the session_key is zero, don't register all IPs at once. Do one first, and when a session_key is received, register the others.
The text was updated successfully, but these errors were encountered:
Okay, the current live master_server is patched to fix this behaviour. Although it is still wrong, it is not an active bug anymore.
Fixing this properly still would be nice, of course ;)
The way it is fixed: if you don't have a session_key set, the MasterServer sends you one, and ignores your request. The way that OpenTTD works, it means that the game thinks the UDP packet got lost in traffic, and resends his register packet again. But this time with a session_key set. That resolves the issue for now, but it is dirty :D
I think a sufficient answer is: for a long time. Somewhere before 1.0.0, and somewhere after 0.4.8, if you want some ranges. That is about as far as I was willing to dissect it.
Version of OpenTTD
Since masterserver protocol v2.
Expected result
When I start a server with dualstack (IPv4 + IPv6), I expect a single masterserver registration with both IPs.
Actual result
The first time, I register two servers: one for IPv4, and one for IPv6. Only when the second announcement happens, they are collapsed into a single entry.
Steps to reproduce
Start a cleanly installed OpenTTD server. Your server will briefly (well, for the next 15 minutes) show up as 2 servers on the serverlist.
What is going wrong?
When a server registers to the master server, initial he does this without a
session_key
(well, it is set to zero). In response, the masterserver will send back a uniquesession_key
to track this server. The idea behind it is that the server can announce on multiple IPs; as long as thesession_key
is unique the masterserver knows that this is the same server with multiple IPs.The server runs registration async; and you can guess now what happens. On the first run, both the IPv4 and IPv6 announce with a
session_key
of zero, indicating the masterserver should allocate one. He does so, two uniquesession_key
s, because the masterserver has no clue this is in fact the same server. In result, two servers show up instead of one.When the re-announcement happens, 15 minutes later, the game did settle on either one of the
session_key
. From this point on, the masterserver collapses the two entries into one, and all is well again.Suggested fix
When the
session_key
is zero, don't register all IPs at once. Do one first, and when asession_key
is received, register the others.The text was updated successfully, but these errors were encountered: