Age | Commit message (Collapse) | Author |
|
|
|
It now follows very simple rules:
0 - Fatal, user should know about this
1 - Error, but we are recovering
2 - Warning, wrong but okay if you don't know
3 - Info, information you might care about
4 -
5 - Debug #1 - High level debug messages
6 - Debug #2 - Low level debug messages
7 - Trace information
|
|
Also changed some levels to 0, as a failing listen() is something
we should tell the user about. Hiding this information is a bit
evil.
|
|
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.
|
|
|
|
|
|
This also means we no longer need last_host/last_port, but can
just use a single last_joined setting.
|
|
|
|
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.
|
|
|
|
|
|
static buffers
|
|
|
|
Emscripten compiles to WASM, which can be loaded via
HTML / JavaScript. This allows you to play OpenTTD inside a
browser.
Co-authored-by: milek7 <me@milek7.pl>
|
|
Remove static buffer form of NetworkAddress::GetAddressAsString.
This is used in multiple threads concurrently, and is not thread-safe.
Replace it with a form returning std::string.
|
|
|
|
|
|
instead of an AutoFreeSmallVector.
|
|
This switch has been a pain for years. Often disabling broke
compilation, as no developer compiles OpenTTD without, neither do
any of our official binaries.
Additionaly, it has grown so hugely in our codebase, that it
clearly shows that the current solution was a poor one. 350+
instances of "#ifdef ENABLE_NETWORK" were in the code, of which
only ~30 in the networking code itself. The rest were all around
the code to do the right thing, from GUI to NewGRF.
A more proper solution would be to stub all the functions, and
make sure the rest of the code can simply assume network is
available. This was also partially done, and most variables were
correct if networking was disabled. Despite that, often the #ifdefs
were still used.
With the recent removal of DOS, there is also no platform anymore
which we support where networking isn't working out-of-the-box.
All in all, it is time to remove the ENABLE_NETWORK switch. No
replacement is planned, but if you feel we really need this option,
we welcome any Pull Request which implements this in a way that
doesn't crawl through the code like this diff shows we used to.
|
|
|
|
"unsafe" functions to prevent them from being used, and thus having to care about certain aspects of their return values
|
|
Eagle_rainbow)
|
|
|
|
'do not resolve anymore' as well, instead of trying to resolve them each and every time the address is accessed
|
|
more likely to be updated [n].
|
|
|
|
>= 32.
|
|
|
|
|
|
|
|
messages by adding more information to them. Also give some clues on how to fix certain issues (like failing advertising).
|
|
|
|
the master socket do that too; too bad getaddrinfo can't handle binding to any address on any port at the same time :(
|
|
you've got an unresolved address, the hostname cannot be resolved either so return it as-is.
|
|
to register an IPv6 address (only if it could ofcourse)
|
|
|
|
of returned server lists.
|
|
passing the hostname and the IP into a string.
|
|
to the config file.
|
|
quite pointless.
|
|
messages when binding
|
|
address binding fails
|
|
masterserver
|
|
|
|
multiple sockets.
|
|
passing it around is easier.
|
|
not provide a nice 'interface', so we have to do it the ugly way.
|
|
|
|
some support for IPv6 netmask matching.
|
|
default value and not all OSes actually support IPv4 over IPv6 so making it the same on all OSes eases debugging and such
|