The connectivity panel may disappear, even if the player isn

[[CPC]Sana]

Bug: when a player crash, the connectivity panel can show up, and might disapear without letting us the time to kick the player.

During one of my last game, the game froze.

Soon after, the connectivity panel showed up, with 1 player (soltpain) having the chrono. Nothing unusual so far.

But he's the issue: The chrono disappeared, like he managed to come back. Except the game remained frozen. The connectivity showed up game soon after, 'till 30sec, then disapeared, game remaining frozen. One of the players ingame said soltpain's PC crashed. Then the connectivty panel showed up once more, and let us kick him.

I had the bug once before, but it seems rare (like 15% of the time someone disconnect).

Thanks a lot for running FAF!


Edit:

My fa.log : http://pastebin.com/GF68P45X
My debug.log : http://pastebin.com/tGZuPkpN
My replay: http://www.mediafire.com/download.php?hm12585fesr3u5q
Happens at 9:40 - 9:50

I'll ask soltpain to post his replay, debug log, when he's back online.

[Ze_PilOt]

First, some explanations :

When playing, the connections between players is completely unrelated to the FAF server. It''s purely peer to peer.

And it's using UDP.
That's mean there is not a constant connection between you and a player. (think of TCP as a water flow between players. You know when the flow stop. UDP is more like sending drops. You know when you receive a drop, but you don't know if you will receive other ones)
That's mean that FA has not real way to know if a player is still here or not.

In order to detect that, he uses several things :

- If a player close his FA, he send a "I'm quitting now" UDP packet to all players. Resulting with a "player has disconnected" message.
If you ctrl-alt-del the game, or close the lobby and terminate FA, or reset his FA, or disconnect from the net, he will not send this. So FA has 2 others things :

- Each UDP packet you send is supposed to have a packet back as acknowledgement.
If the player is not sending it, it will increment a counter. The counter is the "behind data" in ren_shownetworkstat. 20 mean that that player didn't send the acknowledgement for 20 packets you sent.

THIS IS FROM YOU TO OTHERS PLAYERS

That's mean that 2 others players can have "behind packets" (for different reasons) without you having anything weird displayed in "ren_shownetworkstat"

- Each players is supposed to send packets regularly.
If a player is not sending them, same thing happen, more or less.

When the two conditions are fulfilled for a player and all the others, a disconnection screen appears.

If that player is sending/receiving packet again on the same IP as before (ie. after a Wifi disconnection or even a restart of their router), the game will go on again.

In the case of you receiving packets from a player, but another player is not receiving anything from that player, the game will freeze, waiting for these 2 players to communicate again (because all packet are synchronized). It will NOT display a connectivity window.
That's in fact what you call "lag". The game do a micro freeze waiting for others player to synchronize. That happen because of ping, lack of bandwidth, or real network problems. Notice that these freeze won't make your FA unresponsive. The sim freeze, but you can still move your mouse around or maybe chat.

As it's UDP, all this is highly unreliable.
What can happen is this :
-a player crashes. Each player will get "behind" packet, and communicate that infos to others players. That should trigger the connectivity window.
- But sadly, the communication between two others players is fucked for some reasons, but correct for the others.

So, your FA will fails displaying the connectivity windows, and the game will freeze forever. (that's also explain why it can go on again when one these two players leave too).

I'm not sure that what is happening here, but you can see how hard is it to debug that.
The best way is to ask EVERY PLAYER to display their show_networkstat, and that EVERY PLAYER post them (by screenshot) when it's happening.

Without that, it's impossible to debug.

Best way to avoid it is : Don't kill FA when it freeze. You are only aggravating the problem. It can perfectly resume his course between 60 seconds and 4 minutes.

Also, there is another kind of freeze that can happen when FA is sending datas to the server (TCP this time), but don't receive a acknowledgement from it.
This is NOT something I'm doing wrong : it's how the TCP protocol is designed.

These freeze are total : you can't even move your cursor !

THESE ARE PROBABLY NOT PERMANENT.

FA is badly coded network-wise, but the server will probably receive these data and send the ack. At worst, after some minute min, FA will give up and resume.
That can mostly happen when you are defeated : your FA is sending a huge packet to the server (some XML stats). Don't worry, it's not frozen forever.
That's these "game freeze when ACU die" problems : It's not when the ACU dies, but 5-10 seconds later, when the game decide you are defeated, and send the XML stats. If the stats are huge, it can cause some problems.
It happens also on victory.

That was also happening a while ago with livereplay, when the connection was cut or unable to be done : FA was freezing after 4-5 min into the game and was resuming later. This is exactly the same.
We solved the problem by doing a local relay in the lobby. We will probably do the same for these stats in the future.

[[CPC]Sana]

Thans for the long, complete answer!

I posted this "bug" due to the "please report policy", but it's at worse a minor inconvenience if we know we'll be able to kick a player that left.

[Doompants]

Since these problems with FA's network coding are unlikely to be changed (and have nothing to do with FAF), we should spread the word that freezes like can take up to 4 minutes to resolve and recover. If everyone knows, there probably won't be so many bug reports for something that cannot (realistically) be fixed.