Comment 28 for bug 1689087
Revision history for this message
| SirVer (sirver) wrote Re: [Bug 1689087] Re: Implementing a relay server | #28 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
Yup.
> Am 02.07.2017 um 20:01 schrieb Notabilis <email address hidden>:
>
> So simply always start a relay server for internet games, independent of
> whether the game host is reachable?
>
> --
> You received this bug notification because you are subscribed to
> widelands.
> https:/
>
> Title:
> Implementing a relay server
>
> Status in widelands:
> Confirmed
>
> Bug description:
> Two short notices before you continue reading:
> - This bug report is more like a project proposal/
> - The following plans are concerned with the underlying TCP connections of the network gaming and do not affect the gameplay as such.
>
> Currently, when hosting an internet game of widelands the host player has to create port forwarding rules in his router. For a lot of players this is a problem. As a possible solution the introduction of a relay server was proposed quite some time ago [1]. The basic idea is that all players (even the host) are connecting to this globally reachable relay so they don't require any port forwardings on their own systems.
> [1] https:/
>
> Another older request is support for IPv6 [2], which will probably become even more pressing in the future. Since this seems to require a change of the used networking library I would prefer to do it before starting to implement a relay server so we can use the same technology for both.
> [2] https:/
>
> In the following I will describe what I am currently planning to do.
> If you spot any problems or have other comments, feel free to tell me.
>
>
> == Refactoring Step 1 ==
> I renamed NetHost/NetClient to GameHost/GameClient and am working on extracting the network specific parts into new NetHost/NetClient classes (no branch online yet). The plan is to have all network calls hidden so they can be easily replaced.
>
> == Using Boost.Asio ==
> When the classes are extracted, I intend to replace SDL_net with Boost.Asio since there is no IPv6 for SDL_net (only an unofficial modification for an outdated version of SDL_net).
>
> == IPv6 ==
> When we already use Boost.Asio, it should be quite easy to add support for IPv6 in the relevant wideland classes. I haven't tried it out yet but I think it should even be possible to support IPv4 *and* IPv6 clients in the same game without any special handling (as long as the host-computer supports both protocols, of course).
>
> Metaserver:
> The metaserver seems to already support IPv6 based on a quick view through its code. However, the domain name widelands.org can not be resolved for IPv6 so I have no idea whether the metaserver-computer itself supports it yet. If someone could enable it that would be great. No idea whether there are any firewall rules which have to be updated, too. Note that this would probably also affect the homepage.
> Currently the metaserver reports the IP address the game host used to connect with it. In the future it might be worth changing that to allow IPv4/IPv6 participants in the same game.
>
> == Refactoring Step 2: Proxies Part 1 ==
> Since the GameHost does no longer have direct access to the network functions, we can replace the underlying network structure. The idea is that the NetHost class will be replaced by a NetProxy class and a NetRelay (or so).
> The NetRelay is started on the same computer and the NetProxy as well as the clients connect to it. Its task is to simply relay all traffic between the NetClients and the NetProxy. The GameClient and NetClient won't notice any difference compared to talking to the host directly. Since the NetHost and NetProxy classes will offer the same interface, the GameHost shouldn't notice either. Between the NetProxy and the NetRelay the connection will be multiplexed with some simple protocol to allow host messages to/from all/single clients. The clients are only communicating with the host (over the relay) so there is no change required.
>
> Admittedly always using the relay is a small overhead compared to
> using the (removed) NetHost when possible. But it is less code that
> way so I decided in favor of it.
>
> == Proxies Part 2 ==
> With the separation of NetProxy and NetRelay the NetRelay can also be made available as a separate program to run on the computer of the metaserver. The idea is that the metaserver tries to connect to the relay offered by the host. When it works, fine, continue as we do now. If it doesn't, start an own NetRelay on the metaserver and tell the GameHost about it so it connects there. The clients will also be told to connect to the NetRelay, so in that case the game will be relayed over the metaserver.
>
> Note that until here the changes are all locally and should be
> compatible with the netcode of the current trunk. If I am not
> overlooking something it should be possible for trunk-clients to
> connect to the relay on the metaserver without ever noticing it.
>
> == Proxies Part 3 (crazy ideas) ==
> The NetRelay does not necessarily has to run on the metaserver. For example, it could run on the computer of any participant in the game (even observers), reducing the load on the metaserver. The latency would not necessarily become worse since it doesn't matters whether we have the metaserver or some client as an additional hop (besides: We don't have much data anyway).
>
> We would have to teach the client about the relay when doing so,
> though. But then we could even go as far as changing the relay while
> ingame, when e.g. an observer or a loosing player was hosting the
> relay and he disconnects. (For that case we would have to add our own
> segment numbers to packets to avoid loosing any when switching
> relays.)
>
> == Further work ==
> - When the metaserver code is touched anyway we should probably add support for encrypted password transmission on login. The easiest way would something like CHAP. Or we go for a completely encrypted metaserver connection with TLS (which would mean a new library requirement in form of openssl for the clients).
>
> - Currently, when a connection is lost the game has to be re-hosted
> and a savegame loaded. It would be comfortable if the disconnected
> client could simply reconnect to the server even when his IP changed.
> Shouldn't be that difficult since the server is waiting for the client
> and both have stored the same gamestate anyway. This probably even
> works when the server gets lost shortly as long as he tells the
> metaserver his new IP and the clients get it from there.
>
> - Late joins of observers would be a nice feature. In the tournament
> it happened that potential observer missed the start of the match by
> just a few minutes and couldn't join later on. Not sure how much work
> this one is since we have to transmit the game state to the new
> observer, preferably without disturbing the running game.
>
>
> So much for my plans for the next ten years. Any comments, critic or praise are welcome. If no-one protests I will just start working on it and sooner or later there will be some merge requests.
>
> To manage notifications about this bug go to:
> https:/