diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/game_coordinator.md | 64 |
1 files changed, 64 insertions, 0 deletions
diff --git a/docs/game_coordinator.md b/docs/game_coordinator.md new file mode 100644 index 000000000..e8260f2e1 --- /dev/null +++ b/docs/game_coordinator.md @@ -0,0 +1,64 @@ +# Game Coordinator + +To allow two players to play together, OpenTTD uses a Game Coordinator to +facilitate this. + +When a server starts, it can register itself to the Game Coordinator. This +happens when `server_game_type` is set to either `invite-only` or `public`. +Upon registration, the Game Coordinator probes the network of the server, and +assigns the server an unique code, called an `invite code`. + +When a client wants to join a server, it asks the Game Coordinator to help +with this by giving it the `invite code` of the server. The Game Coordinator +will, in this order, attempt several ways to connect the client and server +together: + +## 1) Via direct IPv4 / IPv6 + +Upon registration, the Game Coordinator probes the server to see if a +direction connection to the server is possible based on the game port. It +tries this over the public IPv4 and IPv6, as announced by the server. +If either (or both) are successful, a client will always be asked to try +these direct IPs first when it wants to connect to this server. + +- If the server is IPv4 only, the client is only asked to connect via IPv4. +- If the server is IPv6 only, the client is only asked to connect via IPv6. +- If the server is both IPv4 and IPv6, the client is asked to connect to to + one of those first. If that fails, it is asked to connect to the other. + Whether it tries IPv4 or IPv6 first, strongly depends on several network + infrastructure related events. The biggest influence is the network + latency over both protocols to the OpenTTD infrastructure. + +In the end, if either the server is not reachable directly from the Internet +or the client fails to connect to either one of them, the connection attempt +continues with the next available method. + +## 2) Via STUN + +When a client wants to join a server via STUN, both the client and server +are asked to create a connection to the STUN server (normally +`stun.openttd.org`) via both IPv4 and IPv6. If the client or server has no +IPv4 or IPv6, it will not make a connection attempt via that protocol. + +The STUN server collects the public IPv4 and/or IPv6 of the client and server, +together with the port the connection came in from. For most NAT gateways it +holds true that as long as you use the same local IP + port, your public +IP + port will remain the same, and allow for bi-directional communication. +And this fact is used to later on pair the client and server. + +The STUN server reports this information directly to the Game Coordinator +(this in contrast to most STUN implementation, where this information is +first reported back to the peer itself, which has to relay it back to the +coordinator. OpenTTD skips this step, as the STUN server can directly talk to +the Game Coordinator). When the Game Coordinator sees a matching pair (in +terms of IPv4 / IPv6), it will ask both the client and server to connect to +their peer based on this public IP + port. + +As the NAT gateway forwards the traffic on the public IP + port to the local +port, this creates a bi-directional socket between client and server. The +connection to the STUN server can now safely be closed, and the client and +server can continue to talk to each other. + +Some NAT gateways do not allow this method; for those this attempt will fail, +and this also means that it is not possible to create a connection between +the client and server. |