Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
Adding to the GDPR thing. You are posting in this forum using a username chosen by you. This is personally identifying data. There is no legal way for FAF to show your post to other people on the internet without collecting your permission. (send your complaints to the the european parliament)
Unless you randomize usernames and prohibit people from using free text fields, you can basically not not collect personal data, for which you need people's permission.
This ks actually quite tricky, even my small scripts that present users with a website that remembers them based on IP have to get their consent for GDPR.
In the case of FAF, FAF doesn't collect your data, it doesn't use third party analytics, it doesn't track you or ship advertisements. It actually tells you what exactly is collected in the consent form (see also FAF privacy policy, email for spam prevention, pw reset and contact, username for, well, that should be obvious).
So be happy that you have that control over your data, and if you desire, not to share your username with FAF, then that's your right and you can simply not post here.
Guy who developed the ICE adapter here, Bandwidth of 8 Mbit/s should be fine. I don't have the exact bandwidth requirements in mind, but I remember sth like 20KB/s per player. It's not just the download that matters, but especially the upload. About the traffic, Client and ICE overhead is insignificant, it's 95% compressed game data.
Back when testing ICE, we had a player with 1 Mbit/s download and they weren't able to play anything 8+. So for dual gap I'd say 4+ Mbit/s will be fine. Beware though that the game is peer to peer and therefore traffic symmetrical, you will need the same thing for uplink as well. (Have been playing 16 player games with 2 Mbit/s up for ages).
About latency, that's a different story. You've come at an unlucky time. The FAF server is currently misconfigured, causing the latency estimation to Faforever.com to fail.
ICE tries to establish a direct connection, but uses a fallback in case that might not be possible (due to e. g. a symmetric NAT as it might be the case in a hotel environment).
We've got a relay server in australia specifically for oceanian players, but due to the mentioned current issue, your ICE adapter will not detect that that should be used.
So it relays your traffic via the server in Nuremeberg, for a round trip from player A->B->A, that means A->Europe->B->Europe->A. So you're going 4 times around half the world. That's the reason your in game latency is currently that high.
We're working on a fix. In the mean time, I've also added a workaround into the ice adapter which uses some fallback servers for the latency estimation (not the relaying, just the figuring out of "should I use the oceanian relay").
You can find the new adapter here: https://github.com/FAForever/java-ice-adapter/releases/tag/v3.1.0
I'm trying to get it inro the release candidate soon, you can test it by replacing the faf-ice-adapter.jar in the natives folder in the install dir of the client.
This will cause your adapter to correctly detect that faforever.com is too far away and use the correct relay. If you're lucky, your relay candidate will be used. It might be the case though for some players in your team, that are in oceania too and still run the old adapter, that their, european relay candidate is used, so you may end up with the same issue, till a fix is released to everyone. (although the issue won't be on your side then)
You can also send me an adapter log after testing, then I can take a look which candidates (relay/direct/...) and which relay were chosen.
If you have any other questions / need help / ideas troubleshooting network issues, feel free to message me on Discord (Official FAF server).
I'll see what I can do, it should work out, but hey, this is FAF, so soon.
@youthenoob said in Is it worth me writing a program to check the network?:
I already work in software development and networking, and am now wondering whether it is worth my time (perhaps a day to two) to write some software to test/record the network performance.
It's always nice to have more data on network performance for investigation.
So before I start investing/wasting too much time on this I thought i would get your opinions. The things I was looking at testing were: Ping times to the local gateway, to see if there is jitter (caused by the wifi/bad cabling/s**t router). Ping times to a distant IP address to see if there are ISP issues
So before I start investing/wasting too much time on this I thought i would get your opinions. The things I was looking at testing were:
You can do some latency tests, although I usually just point people to ping.canbeuseful.com for running a latency test during the game, I think weak WiFi links aren't the issue in 99.9% of games, most people are smart enough to think of that themselves.
iPerf (bandwidth tester), to see the max bandwidth the user has
That would be quite interesting, you could add information to your tool that tells the user what games they will be able to run (2v2, 4v4, 5v5, 6v6, ...). Bandwidth scales rather linearly with peer count, up / down bandwidth is symmetrical.
The bandwidth used during gameplay, to see if something else is taking all of it (vs total bandwidth).
If you can monitor / obtain info about other system traffic that might be interesting to discover background load, like steam updates.
Traffic in FA consists of 2 packets per peer per tick. 10 Ticks per second. One of those packets is ~15 bytes, the other one is ~25-70 bytes.
Nvidia driver version (to test for the old driver issue) Whether the user is using Global Carrier NAT; games get routed through a relay and ping times are added.
That would also be quite interesting.
A lot of data is also available from the ice adapter debug window, which is currently not visible due to the client not having a JRE with JavaFX. The ICE adapter already measures latency to each peer. It can also tell you which candidate pair it chose for each peer (host, prflx, srflx, relay), from which you can infer information about network and NAT architecture.
The best option would probably to add some of those measurements to the ice adapter itself, as it has already gotten access to the traffic as well as quite a bit of other debugging information. You can e.g. just start counting game traffic here: https://github.com/FAForever/java-ice-adapter/blob/master/ice-adapter/src/main/java/com/faforever/iceadapter/ice/PeerIceModule.java#L390
Not sure if that's an option for you though, language-wise as well as taking into account you want to access system traffic info and want to perform measurements to local gateway.
Forwarding ports is unnecessary. The error you posted is normal.
The main issue is this:
java.util.concurrent.CancellationException: null at java.base/java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2468) at com.faforever.iceadapter.ice.PeerIceModule.lambda$gatherCandidates$4(PeerIceModule.java:118) at com.faforever.iceadapter.util.Executor.lambda$executeDelayed$0(Executor.java:16) at java.base/java.lang.Thread.run(Thread.java:832) Nov 30, 2020 8:17:08 PM com.nbarraille.jjsonrpc.JJsonPeer sendNotification INFO: Sending Notification:{"method":"onIceConnectionStateChanged","params":[82574,47273,"disconnected"],"jsonrpc":"2.0"} Nov 30, 2020 8:17:08 PM org.ice4j.util.Logger log INFO: ICE state changed from Waiting to Terminated. Local ufrag 357851eod9cggh Nov 30, 2020 8:17:08 PM org.ice4j.util.Logger log INFO: Failed to receive: java.net.SocketException: socket closed Nov 30, 2020 8:17:08 PM org.ice4j.util.Logger log INFO: Closing. Nov 30, 2020 8:17:08 PM org.ice4j.util.Logger log INFO: Failed to receive: java.net.SocketException: Socket closed Nov 30, 2020 8:17:08 PM org.ice4j.util.Logger log INFO: Failed to receive: java.net.SocketException: Socket closed Nov 30, 2020 8:17:08 PM org.ice4j.util.Logger log INFO: Failed to receive: java.net.SocketException: Socket closed Nov 30, 2020 8:17:08 PM org.ice4j.util.Logger log INFO: Failed to receive: java.net.SocketException: Socket closed Nov 30, 2020 8:17:08 PM org.ice4j.util.Logger log INFO: Failed to receive: java.net.SocketException: Socket closed Nov 30, 2020 8:17:08 PM org.ice4j.util.Logger log INFO: Failed to receive: java.net.SocketException: Socket closed
This means your operating system or antivirus is closing the socket and not telling the adapter why. This only occurs on less than a few percent of devices. I spent a lot of time debugging that and sadly didn't find a solution, the issue lies somewhere within proprietary code of your operating system manufacturer.
Try the options suggested in https://wiki.faforever.com/index.php?title=Connection_issues_and_solutions#Unable_to_connect_to_someone in the order they're listed in. Each is more likely to fix the issue, e.g. VPN worked on one of my machines when I had that issue.
Fix is not released yet but in the works, faforever.com seems to respond to ICMP echo again though. I guess a server admin changed something.
So the old ice adapter should work normal again.
@askaholic said in LanCache.NET support:
I think in theory ICE is supposed to be able to discover when you’re playing on LAN and connect directly. Not sure if it actually works though because I haven’t had any luck with it. @Geosearchef would know more about that.
ICE will connect directly in a local network, yes, but this is about caching content requests to the server. I do not really see the point about that though, given the amount of data to be shipped as well as the issue with https encryption.
@askaholic said in Introducing Mapgen Week on Ladder:
Let’s rename it to "Neroxis and Sheikah Map Generator". And while we’re at it let’s rename the faf client to "Downlords and Axels and Brutus’ and Sheikahs and All those other guys FAF Client"
How about Askaholic's FAF server? Can I give the ice adapter a nICE name? In all seriousness, we should remove people's names from those projects. This applies especially to the client, which only contained Downlord's name as he was asked to distinguish it from the official FAF client and name it unofficially, instead of using sth like "FAF Client 2.0", ... .
Just dropping by to say this is awesome! Can't wait to finally play a normal 4v4 using matchmaking. No map picking, no pre determined spots, just pure FA.
@veteranashe That's hard to do implementation wise. People might queue up for that queue in a party of 4. Dynamically scalling that down requires a lot of complexity in the code as well as the algorithm used for matching.
@Krieggs You can give this a read: https://forum.faforever.com/topic/2264/moved-to-australia-is-it-still-possible-to-play/7 I get asked this question about the inner workings of the ice adapter quite a lot, I think I should write that down in the Wiki in more detail.
@quatermain The statuspage is manually updated, so most of the time, when they do not have time to fix the server, they also don't have time to update the status.