-
Notifications
You must be signed in to change notification settings - Fork 88
Proxy2.0
-
the server determines that peers need to connect via proxy
-
the server generates a UUID and sends UUID + 0x00 to peer A and UUID + 0x01 to peer B and additionally sends a HMAC of UUID + shared_secret. This is send as part of the ConnectToProxy message and thus the lobby associates a UUID with a player connection.
-
the lobby of peer A sends UUID+0x00+HMAC to the proxy UDP port. Since the proxy does not yet know about the source IP:port of peer A, it inspects the message, verifies the HMAC with the shared_secret that it shares with the server and maps the UUID+0x00 to the peer IP:port. the proxy confirms reception of the triplet to peerA (reliable transmission).
-
peer B send his triplet to the proxy. All further steps as in 2), but the proxy finds the mapping of the UUID to peer A and creates a mapping peerA(IP:port) to peerB(IP:port) and a mapping peerB(IP:port) to peerA(IP:port).
-
when a packet arrives from peerA(IP:port) or peerB(IP:port) the proxy will find a mapping to the other peer and will send the packet to the associated port without altering it.
-
teardown of all mapping is by timeout. ca. 3 minutes. Since any peer could be starting another game and send a fresh UUID triplet to the server and by chance or firewall oddity use the same source IP:port, there should also be a mechanism by which a peer can invalidate a certain UUID and thus tear down a mapping manually. The proxy would have a second well known port for these messages. This will only be necessary if the peer's NAT has a mapping timeout <3 minutes and additionally by chance or oddity reuses the same port for the new connection.
bumping https://github.com/FAForever/fa/wiki/Build-a-star-topology-game-protocol to say that a small amount of info published about the framing vs. game udp packets enables a tcp central server model that could eliminate desync and decimate the packet costs on the amsterdam server.