ICE Adapter UI

The FAF ICE adapter aims at managing all connections for the game. It's a program running on your local system started/stopped by the FAF client that offers an interface to the game. The game is then told by the FAF server/client/adapter to connect to other players, supplying it a wrong IP address. If you then join a FAF game, your game will think all of your peers it's connected to are located on your local machine. It sends all its traffic to the ice adapter, which then figures out how to forward it to the other players' ice adapters, which then forward it to their games.

The ICE adapter uses the Interactive Connectivity Establishment (ICE, standardized as per RFC5254) to, well, interactively establish connections.

For each player you connect to, the ice adapter will run ICE to establish a connection. The process can be broken down into the following steps:

1. Gather candidates
2. Send candidates to the other player's adapter via the FAF server
3. Receive candidates from the other player's adapter via the FAF server
4. Form pairs of candidates (one local candidate, one remote candidate for the other player)
5. Try to reach the other player on all pairs (using the local address, sending to the remote candidate)
6. Pick best pair to succeeded, nominate, confirm (if failed, disable non relay candidates, go to step 1)
7. Start communication
8. (monitor connection, echo requests, once per second, restart on connection loss)

The following types of candidates exist (the last one is not relevant for FAF):

• HOST: a candidate obtained from a local interface, this is an IP address someone in your own network can reach you at (for local connections)
• SRFLX: server reflexive - a candidate obtained by asking a STUN (session traversal utilities for NAT) server, where do you see this request coming from - usually your “public IP”
• RELAY: a relay candidate, this is basically a TURN (traversal around NAT using relay networks) server borrowing you its public IP address and port, you can use it by sending data there through a tunnel
• PRFLX: peer reflexive - a candidate obtained by asking another player, already connected to, where they see the request coming from - allows connection e.g. within autonomous systems, other WANs, without using the internet

So in step 1, your adapter wil gather all possible candidates, e.g.

• host 192.168.0.10:6120 (your local IPv4)
• host [fe80::2d5d:1a01:9e2b:4ac1]:6121 (your local IPv6)
• srflx 1.2.3.4:6122 (your public IP)
• relay 116.202.155.226:12345 (faforever.com relay)

It will then send those to the other peer and receive their candidate list (analogous, step 2 and 3).

It will then open a ton of sockets and start talking to the other side (4-7). When it reaches someone, it will attempt to communicate, and then establish connection on the preferred pair, an example list of pairs:

• host<->host
• host<->host
• srflx<->host
• host<->srlfx
• relay<->srlfx
• relay<->relay

A relay connection will always succeed, therefore in theory the adapter should always be able to connect.

Side note for developers: One adapter is in offerer mode, the other in answerer mode. Game host is always offerer. Offerer sends candidates first, decides on the chosen candidate pair and monitors the connection.

TL;DR: Blindly adding more coturn servers doesn't help. But adding coturn servers with good connection across the globe helps to reduce lag in international games.

Coturn is an open source server that provides all the features required to implement the ICE protocol. The ICE adapter needs a coturn server to connect to.

In theory a single coturn server is sufficient to make connectivity work. However, when the ICE adapter uses a relay connection, the round trip time between the player and the coturn server adds up twice on top of the direct round trip time to the remote player.

A simple theoretical example: Alice and Bob live in Australia. They are connected in the same network and have a theoretical round trip time of 1ms. However, for some reason, a relayed connection to the FAF Coturn server in Europe is required. Now each packet from Alice to Bob has to travel to the Coturn server in Europe and back to Australia.

Australia and Europe are 13000 km apart. Even in perfect scenario with a fibred connection in a straight line at the speed of light (200000 km/s) a packet still requires at least 65ms, making it an additional 130ms. The real world round trip time is much worse of course.

This is the reason why people had issues with Oceanian players. As long as only 1 player comes from Oceanian and the rest is European, the roundtrip only adds up once. But if 2 Oceanian players join it adds up twice, the game will most probably lag.

If we now set up an additional coturn server in Australia, Alice and Bobs round trip time is reduced massively, therefore reducing lag issues for all players.