Player disconnecting too fast on subsequent disconnects

Hi. I am developing an Oculus Go game and any time after the player disconnects by taking off their headset or going to the Oculus Home menu, their next disconnects happens after 10 seconds which is too fast. I am using PUN 2.

The scenario is this:
1. First player makes an online room.
2. Second player joins and then goes to the Oculus Home menu by pressing the button on their controller.
3. Second player disconnects after about 1 minute (this is intended I believe since PhotonNetwork.KeepAliveInBackground is set to 60 by default).
4. Second player is kicked out of online. Tries to go back to the lobby menu to re-join the room.
5. Second player goes to Oculus Home menu. This time disconnecting in about 10 seconds.

How am I able to make the second, third, fourth, etc disconnects the same amount of time as the first? This seems like a bug.

Comments

  • The difference will be if the app is in background or closed (most likely).

    If the app is in background:
    For the duration of the BackgroundTimeout, the client will (try to) keep the connection while suspended. Incoming messages are queued and if the client gets focus again, all queued messages are going to be dispatched.
    While in background, the client could run out of memory or disconnect. You can tune the BackgroundTimeout to avoid issues.

    If the app quits or ends, the client will not keep the connection. It should try to disconnect but if that doesn't happen, the remaining players will see the timeout after 10 seconds.


    If the app is in background in both cases but behaves differently, you should possibly update PUN. We tuned this behaviour several times.


    In some cases, it may be actually cleaner to disconnect the client. If you create the room with a PlayerTTL value, a disconnected client can keep it's slot in the room and re-connect to the room. In this case, the remaining users see the client become inactive and active again. The PlayerTTL is a server-side timeout for this case.
    There is one problem in this case: PUN makes sure all objects are under someone's control all the time. The Master Client takes control of objects of inactive players. When a client returns to a room, this player is not in sync about ownership of networked objects and initially doesn't know where the objects are now.
    We didn't solve this yet, as the solution would require server-side support. If it's a problem for you, depends on the use case.

    So overall, I would recommend using a fitting BackgroundTimeout.
  • Thanks Tobias.

    I've already tuned BackgroundTimeout but still getting the 10 second disconnect on the second time I rejoin a room. I looked deeper into this and StartFallbackSendAckThread() in PhotonHandler doesn't seem to get called again after the first time you connect to Photon, so BackgroundTimeout doesn't work after the first disconnect.
  • Which version of PUN are you using now?
    I don't see a call to StopAllBackgroundCalls() in PUN 2 (anymore), unless the connection handler is destroyed or the app quits. So in theory, a second call to StartFallbackSendAckThread() isn't needed.

    This may be different in your PUN version. Let us know.
  • I am using PUN 2.9, Photon Lib 4.1.2.10.
  • I can not yet reproduce this. The PhotonHandler stays the same during the run time and no matter if my client times out or if I disconnect manually, the fallback thread also stays active.

    Could you debug this case and add logging to StopFallbackSendAckThread()? This should be the only case which stops the fallback thread, except there is some issue on Oculus Go.
    Can you reproduce this on windows (running the same app)?
  • I added some debugging logs on StopFallbackSendAckThread() and found that it was being called only on one instance during runtime. It was being called on PhotonVoiceNetwork when I destroy my voice objects after leaving the room because I did not need voice when I'm not in a room.
  • I missed the fact you're using Voice. That could indeed be a problem.
    Will forward this for investigation / fixing.
  • Hi @CheeseBrownie,

    PUN and Photon Voice use two different fallback threads.

    I think what you see with StopFallbackSendAckThread being called from PhotonVoiceNetwork is the correct behaviour since you are removing the voice objects when leaving the room.

    But you may as well put PhotonVoiceNetwork on a separate distinct GameObject and not remove it when the client leaves the room. This way you won't have to re create it each time and it can keep the connection and alive and make voice connection workflow faster.
Sign In or Register to comment.