StartFallbackSendAckThread() not working properly on Android X

LaiLai
I'm using Photon PUN (newest version) with On-Premise (V4 lastest) Photon Server. When my application change state to paused, the PUN called method StartFallbackSendAckThread() and this method will try to start one thread to keep pinging to server to avoid timeout disconnect after period of time
I have tested on Android X thread is running, server still received ping packet but client still got timeout disconnect, and server log peer is timed out disconnect too.
But it doesnt happen on Android 9 or lower.
Did anyone tested it ?

Comments

  • TobiasTobias admin
    We did not specifically test Android 10, no.
    After which time did that client timeout? There is a time limit after which the client will not keep the connection in background to avoid endless connections from Android apps (which usually just go to the background rather than exiting).
    It may even make sense to timeout / disconnect. Else, other players assume that the user is online (but isn't) forever.
  • LaiLai
    edited July 30
    Tobias wrote: »
    We did not specifically test Android 10, no.
    After which time did that client timeout? There is a time limit after which the client will not keep the connection in background to avoid endless connections from Android apps (which usually just go to the background rather than exiting).
    It may even make sense to timeout / disconnect. Else, other players assume that the user is online (but isn't) forever.
    Thank for your support, i know the workflow and i dont wanna keep connection forever too. It will waste more resources both server and client side. When i use Android 10 client always disconnect when it reached peer.DisconnectTimeout (i set it default is 10 secs), but send acks thread timeout i set it to 500 secs and still got disconnected after 10 secs. All of my devices i tested always send ping packet (i captured it by wireshark and snort) but only got this issue on Android 10 (it still send ping but i dont know why). I just tested on Android 10 with samsung galaxy note 9 and galaxy S10
  • This may be a new restriction on Android 10. iOS did this all the time: When the app goes to background, the OS will close the sockets right away.

    The important part is: When the OS closes the socket right away, the client may be unable to send a "disconnect" message. This means the other clients do see a timeout, even though the Android 10 client immediately lost all network capability.

    Unless there is a setting for this behaviour, it may mean that Android 10 will simply disconnect quickly. Use ReconnectAndRejoin() to get back into the room quickly. You need to set a PlayerTTL in the RoomOptions when you create a room, so that a user may rejoin (after losing connection).
  • Tobias wrote: »
    This may be a new restriction on Android 10. iOS did this all the time: When the app goes to background, the OS will close the sockets right away.

    The important part is: When the OS closes the socket right away, the client may be unable to send a "disconnect" message. This means the other clients do see a timeout, even though the Android 10 client immediately lost all network capability.

    Unless there is a setting for this behaviour, it may mean that Android 10 will simply disconnect quickly. Use ReconnectAndRejoin() to get back into the room quickly. You need to set a PlayerTTL in the RoomOptions when you create a room, so that a user may rejoin (after losing connection).

    Thank you for your info about this problem. I'm finding the way how to restricted it.
  • If you can, let us know what you changed to make it work.
    It's always nice if a forum thread has some conclusion...
Sign In or Register to comment.