Hostnames like "content.openttd.org" resolve into multiple IPv4 and IPv6.
It is possible that either of the IPs is not working, either due to
a poorly configured OS (having IPv6 but no valid route), broken network
paths, or a service that is temporary unavailable.
Instead of trying the IPs one by one, waiting for a 3s timeout between
each, be a bit more like browsers, and stack attempts on top of each
other with slight delays. This is called Happy Eyebells.
Initially, try the first IPv6 address. If within 250ms there is no
connection yet, try the first IPv4 address. 250ms later, try the
second IPv6 address, etc, till all addresses are tried.
If any connection is created, abort all the other (pending) connections
and use the one that is created. If all fail 3s after the last connect(),
trigger a timeout for all.
We now resolve the connection_string to a NetworkAddress in a much
later state. This means there are fewer places constructing a NetworkAddress.
The main benefit of this is in later PRs that introduce different types
of NetworkAddresses. Storing this in things like NetworkGameList is
rather complex, especially as NetworkAddress has to be mutable at all
times.
Additionally, the NetworkAddress is a complex object to store simple
information: how to connect to this server.
Split the updating in a "static" version that only needs to be called when a new map is loaded or some settings are changed, and a "dynamic" version that updates everything that changes regularly such as the current game date or the number of spectators.
Under normal circumstances the server's ID is 32 characters excluding '\0', however this can be changed at the server. This ID is sent to the server for company name hashing. The client reads it into a statically allocated buffer of 33 bytes, but fills only the bytes it received from the server. However, the hash assumes all 33 bytes are set, thus potentially reading uninitialized data, or a part of the server ID of a previous game in the hashing routine.
It is still reading from memory assigned to the server ID, so nothing bad happens, except that company passwords might not work correctly.
One could join a network game from within an already running network game. This would call a NetworkDisconnect, but keeps the UI alive. If, during that process the join is aborted, e.g. by cancelling on a password dialog, you would still be in your network game but also get shown the server list.
Solve all the underlying problems by falling back to the main UI when (re)connecting to a(nother) server.
This means that pressing Refresh button and adding servers manually
now uses TCP.
The master-server and initial scan are still UDP as they will be
replaced by Game Coordinator; no need to change this now.
If we query a server that is too old, show a proper warning to the
user informing him the server is too old.
The idea is that if you query an older server that does not support
this packet yet, the client receives an error. The assumption was
that on every "illegal packet" the connection would be closed. This
turns out to be false.
Now CLIENT_GAME_INFO aligns with the old PACKET_CLIENT_NEWGRFS_CHECKED,
which does a pre-check (which fails), and an error is sent back
and the connection is closed.
This is not a nice solution, but it is the best we got.
The lobby of a server requested some parts via UDP and some via
TCP. This is strictly seen fine, but for future extensions it
is a lot easier if just one protocol is used.
Currently we use default OS timeout for TCP connections, which
is around 30s. 99% of the users will never notice this, but there
are a few cases where this is an issue:
- If you have a broken IPv6 connection, using Content Service is
first tried over IPv6. Only after 30s it times out and tries
IPv4. Nobody is waiting for that 30s.
- Upcoming STUN support has several methods of establishing a
connection between client and server. This requires feedback
from connect() to know if any method worked (they have to be
tried one by one). With 30s, this would take a very long time.
What is good to mention, is that there is no good value here. Any
value will have edge-cases where the experience is suboptimal. But
with 3s we support most of the stable connections, and if it fails,
the user can just retry. On the other side of the spectrum, with 30s,
it means the user has no possibility to use the service. So worst case
we annoy a few users with them having the retry vs annoying a few
users which have no means of resolving the situation.
Especially if there are many players online, trying to chat with
the right one can be a visual challenge. This can be solved by
highlighting the row you are on. This visual cue is often enough
for humans to find the right row.
Patric Stout
rubidium42
rubidium42
Peter Nelson
Loïc Guilloux
Milek7
Charles Pigott