How to organize an ICE test game

[Geosearchef]

The ICE adapter is an attempt to fix most connection related issues in FAF. It does so by proxying all FA related traffic through a local adapter started by the FAF client on your computer.

Sadly this isn't as easy in practice as it sounds. The fact that there are a lot of unpredictable machine and network setups makes this hillariously hard which is also the reason for the ICE adapter being already 2 years in developement and having been rewritten 5 times by multiple people.

To test this adapter we need people to help organizing test games. It's pretty straight forward, if you wanna help, pls pm me (preferrably on a more suitable communication channel than this forum), sry for this yet unstructured post.

General (short) info on ICE:
You don't need to know this, but it can help you identify if a player is e.g. being proxied / what the adapter's current state. is

Spoiler: show

ICE is a standardized protocol for interactively establishing connections between peers possibly behind a NAT (the reason why there are multiple PCs in your network all using one global IP and why you need to forward a port). It does so by using the 2 protocols STUN and TURN.

To establish a connection ice does the following:
1. gather candidates (at which the other peer can reach me), adapter state: gathering
2. send candidates to other peer, adapter state: awaitingCandidates
3. build pairs of candidates, local <-> remote, and check which of them can be used for communication, adapter state: checking
4. succeed or fail

There are 3 (4) types of candidates: (which can be seen in the local/remote columns of the debug window)
1. Host candidate (and address on your local interface, will be used for LAN connection, sometimes in combination with srflx, this means a direct connection)
2. Srflx candidate (basically your global IP as seen by asking a STUN server, this means a direct connection, maybe involving hole punching)
(3. Prflx candidate )
4. Relay candidate (a public IP "borrowed" from a TURN server which can be used to communicate with other peers, this is as the name suggests a proxy connection)

If one of the 2 peers, local or remote is a relay candidate, the connection is effectively proxied, as the other peer will only be connecting directly (srflx/host) to a proxy which yields no benefit.

There is an ICE Tester group on discord that can be pinged (search for @Tester), I recommend pinging in advance and scheduling a time to get more people.
(((Do not run test games with less than 7-8 people, preferrably with 10-12 players.))) People can stay observer, to ICE it will be the same as having a normal player in game, although around 3/4th should be playing as the traffic will decrease if players don't give commands.

The ICE Tester group on discord can be joined/left using

Code: Select all

!subscribe ICE Tester
!unsubscribe ICE Tester


There is a guide explaining how to install and run the client for users here: viewtopic.php?f=45&t=16844
Please make sure players always run the newest available version of that client.

Keep an eye on unexpected issues (high latency, people not connecting, timeing out in lobby, ...), REFAFING is NEVER to be expected. Just pm me about those.

Please measure the realtime and the ingame time and enter them into the provided spreadsheet.

The connectivity screen in the python client can be opened by right clicking the FAF logo in the top left, in the java client there will be a debug window.

To open the debug window in the python client add this to %appdata%/ForgedAllianceForever/lobby.init

Code: Select all

[iceadapter]
args=--debug-window

and copy a JRE somewhere found on your system to replace C:\Program Files (x86)\Forged Alliance Forever Beta\lib\ice-adapter\jre .

In the debug window you can also see the current latency to a peer aswell as the last time a packet was received from them (updates every second, if this goes up that means you're currently not receiving packets from that person). In every connection one peer will be the offerer, one will be the answerer, this is indicated by the localOffer column. You will only see data (-1 elsewise) for the peers where you are the offerer, which you will always be as the host.

Please keep an eye on latency and lastRecv when issues occur aswell as what the state of the ice adapter is doing (->new->gathering->awaitingCandidates->checking->connected->disconnected->).

If the game freezes, the "behind" value in the connectivity screen inside the game (F11) will show you from whom you are still expecting packets, meaning this person disconnected from someone else.


After the game, please ask players that experienced/caused issues to send you their logs as described in the how to join an ice test thread linked above.
At the end of the test, create an entry in the spreadsheet, columns are explained there and pm me with a short summary of incidents recorded.