-
Notifications
You must be signed in to change notification settings - Fork 88
IPv6
When a game is hosted, the server instructs FA.exe to send a NAT packet back to the server on port 30351. This initial NAT exchange is currently essential to learn the public port that the NAT device assigns to UDP packets originating from FA.exe. All SendNatPacket and ProcessNatPacket messages are relayed through the Lobby (class Relayer in src/fa/relayserver.py).
SERVER changes: the server should not send an IPv4 address in that nat packet, but instead a hostname.
LOBBY changes: The lobby shall not relay SendNatPacket to FA.exe, but instead send the NAT packets via UDP itself. This already requires that the lobby and not FA.exe occupies the game port (default: 6112), by the same mechanism that is used for p2preconnect. The Lobby resolves the hostname in the SendNatPacket to both the IPv4 and IPv6 address.
SERVER changes: The server now may learn the following combinations of the public endpoint addresses: IPv6:port + IPv4:port or IPv6:port or IPv4:port. The server must be changed to support the possibility that the player is known by 2 endpoint addresses.
Currently when a player joins a game, the server will issue a series of SendNatPacket messages to that player and will learn whether the NAT packets between 2 players are received from the ProcessNatPacket responses.
SERVER changes: the server shall send all available endpoint addresses of the third party peer to the connecting player.
LOBBY changes: The lobby shall not forward the NAT messages to FA.exe but implement their functionality itself.
SERVER changes: the server shall pick a protocol to use to connect 2 peers from what it learns about the connectivity between the peers and send the proper ConnectToPeer message (that is a single ConnectToPeer message for only 1 protocol)
LOBBY changes: the lobby will use the mechanism used for p2preconnect to speak whatever protocol necessary to the third party peer and communicate with FA.exe via IPv4 on localhost:port. That means that the lobby will intercept the ConnectToPeer message, connect via UDP to the address therein and send a ConnectToPeer:localhost:port to FA.exe. After which it will forward between the localhost endpoint and the public endpoint of the peer.
The NAT protocol (/ASKREPLY and /PLAYERID) should be changed to also measure round trip time of the NAT packets to allow the server to choose the shorter path between the peers. 2 native IPv6 hosts can be expected to have better connectivity between themselves via native IPv6 but still be able to communicate to IPv4 hosts via mechanisms such as NAT64. Likewise native IPv4 peers that are connected to IPv6 networks via 6to4 tunnels are expected to be reachable amongst themselves via IPv6, but with an added delay. Whether communication between a native IPv4 host with IPv6 tunnel support and a native IPv6 host with NAT64 is more efficient via IPv4 or IPv6 cannot be said a priori.
LOBBY changes: the lobby should be able to act upon ConnectToProxy messages where the proxy is a IPv6 address. the lobby before p2preconnect already supports talking to FA.exe through IPv4-localhost:localport exclusively.
SERVER changes: The initial port discovery on server port 30351 should include round trip time mesaurements too and the server should pick the best protocol for proxy communication.
...the last is the least: All TCP connections to the server should be possible via IPv6, which requires the network code of the lobby and the server to be made protocol agnostic, if QT not already provides this out-of-the-box. The drawback of going through a 6to4 tunnel or NAT64 are not too severe for the non-game connections though.