PhotonNetwork.KeepAliveInBackground takes 10 seconds longer than expected to disconnect

kiam3dat
2021-07-09 16:38:03

During the automatic match making and game mode selection process of our game, we've run into an issue where some players will either lock their mobile device or switch to another app while the game is in the game mode selection phase. Because we depend on both players to automatically send a "Ready" RPC once they are ready to load a level, when this happens, the opposing player gets softlocked until the other player either opens the app again, or they automatically disconnect.

To mitigate this issue, we would like those players to automatically be disconnected after just five seconds of pausing the app while in the game mode selection phase. The other player then automatically wins that game, as it is counted as a forfeit. To achieve this automatic time out, we set PhotonNetwork.KeepAliveInBackground to 5 seconds.

The issue is that, no matter what value we set KeepAliveInBackground to, it always takes 10 seconds more than that for the player to actually disconnect. We already looked into lowering PlayerTtl in case that was somehow causing the extra delay, but that was already set to 3 seconds, and therefore cannot explain the 10 second delay.

How can we get rid of this delay?

Comments

kiam3dat
2021-07-13 15:21:46

Is there any solution to this? The wait time introduced by this issue hurts user experience quite a bit since most of our matches only last for about a minute or so. A 10 waiting time where seemingly nothing is happening is pretty long in comparison.

JohnTube
2021-07-13 16:16:28

Hi @kiam3dat,

Thank you for choosing Photon!

Here is what's happening:
The fallback background keep alive threads will keep sending ACKs only to the server to maintain the connection with the server. This will last for KeepAliveInBackground milliseconds.
Once that expires, the client will stop sending ACKs and the server will keep the client connected for another 10 seconds which is the timeout window. If the client does not resume (app regains focus or moves back to foreground) the client will be disconnected after 10 seconds.

So my colleague @Tobias was kind enough to look into this and add an option for the client to gracefully disconnect explicitly once KeepAliveInBackground expires. (even though PUN is in feature freeze mode now that Fusion is here).

Here is the new ConnectionHandler.cs file, should be applied on top of 2.33.3.
You need to change default value of ConnectionHandler.DisconnectAfterKeepAlive to true.
I guess we will make it easier to change this from PUN in the future, currently the only way is to have PhotonHandler in the scene and set DisconnectAfterKeepAlive to true via Inspector in Unity Editor.

I will test this on Android from my side.

EDIT: Update: my tests show that it works as expected, the 10 extra seconds of timeout are gone.

kiam3dat
2021-07-14 10:18:15

Thanks for the response, @JohnTube!

When I get the chance, I will update to 2.33.3 and apply the ConnectionHandler change.

Just so I am aware of any potential issues: given a KeepAliveInBackground value of 5, can we reasonably assume that we won't get any unwanted disconnects due to the main thread stalling during a "legitimate" level selection phase? This phase consisting of some negligible procedures being run (to update UI, update parameters etc), followed by the start of an asynchronous level load. We will set DisconnectAfterKeepAlive to false, as well as setting KeepAliveInBackground to a more lenient value, before the activation of the aforementioned asynchronously loaded level, therefore avoiding the potential hang up during scene activation.

JohnTube
2021-07-15 11:44:25

Hi @kiam3dat,

The KeepAliveInBackground is also used when loading scenes so your workaround of increasing it before scene loading is good.

If an update to 2.33.3 is difficult, I think you can try to use that ConnectionHandler on top of the PUN version you have if it's not too old as we didn't change it that often. You should use version control or have a backup though.