-
Notifications
You must be signed in to change notification settings - Fork 88
P2PReconnect
To facilitate p2p reconnect, all udp peer connections are routed through FAlobby. FA.exe only sees peers on localhost:port. Exchange of management messages happens on the same UDP connection as regular game traffic. Packets on this connection that have the first 15*8 bits set to 1 are not forwarded to FA.exe, but inspected by FAlobby.
As soon as 2 peers are connected ("Connected" message send to server), 64 bit random numbers are exchanged to identify peer connections. peer A sends peer B a 64bit tag, and peer B sends peer A a different tag. tags are acknowledged (reliable transmission). the number of total tags is thus 2 times the number of p2p connections. The ratelimit of tag offer messages is 1 per 5 seconds with 10 tag offers send at most.
When no packets arrive on any peer connection from the internet for 10 seconds, a changed IP address is assumed. all connections are marked as being in a 'reconnecting' state.
The emission of reconnect messages are triggered by activity on the FA.exe facing legs of the connection, those are guaranteed to be active for any connection that FA.exe still associates with a peer. When a connection is tagged as in reconnecting state, a reconnect message is sent to peer B, which includes the tag that was offered to peer B before. peer B sees a new connection from a yet unknown new peer, because it did not originate from any address known to peer B. When a reconnect message is received by peer B, it searches among all connections for the one that has the associated tag and then updates the peer A's address:port in that old connection to the address associated with the new connection on which the reconnect message was received.
As soon as peer B's address is updated, the link is reestablished as far as both FA.exe instances are concerned. To acknowledge the fact for the reconnect logic, peer A tries to confirm the tag that was sent to peer B originally over the new connection.
When a link was severed not due to an IP address change, all peer connections of peer A will be tagged as reconnecting. reconnect messages will be emitted. all other peers receiving those messages will receive them on their original connections and simply ignore them: they simply ignore all reconnect messages where the tag in the message equals the tag associated with peer A's address:port.
When peer A totally crashes, no reconnect messages will be send, because links are only tagged as in a reconnecting state, when no data from any peer arrives for some time. Similarly all peers but peer A will not send reconnect messages because for them the condition that no peer communicated with them is never true. This is not true in a 1v1 game: there neither peer can know if his own address changed and that will result in both peers sending reconnect messages. peer A's reconnect messages will be processed normally. peer B's reconnect messages will be ingored normally.
Reconnecting to the proxy is simpler, because the proxy protocol can handle reestablishment of the TCP connection as is. All that is needed is to detect that no data was received from the proxy for 10 seconds and then reestablish a new TCP connection. No specially crafted messages must be send.
When peer A gets a new IP address it will not be able to send a reconnect message to peer B if peer B's NAT does endpoint filtering. to establish a new UDP connection, it has to originate from peer B (udp hole punching). peer A will first try to send reconnect messates to peer B and after a while will start sending reconnect-by-intermediary messages to other peers with whom a normal reconnect was successful. peer C after being reconnected with peer A will accept reconnect-by-intermediary messages, which contain the tag that peer A originally sent in normal reconnect messages to peer B. peer C will then send reconnect-by-intermediary-2 messages to all known peers and include the tag and the source IP:port of the R-by-I message received from peer A. when peer B receives the R-by-I2 message from peer C it will treat it as a normal reconnect message from peer A (regarding the tag), but will use the IP:port of peer A that is in the R-by-I2 message. This works, because peer A's NAT does not do endpoint filtering. Otherwise no direct UDP connection would have been possible between peer A and B in the first place.
if the only peer without NAT endpoint filtering disappears from a game, no reconnection will be possible by the peers without the intervention of a 3rd party. The server should be made to act as a reconnect-by-intermediary pseudo-peer in that case. Also it would be beneficial to allow 2 peers to connect via the FAF proxy if reconnecting fails. In the current state p2p_reconnect cannot "upgrade" the connection.