Disconnection occurs every time the browser is minimized on mobile

[Aigul9]

[DrAnax]

Further tests confirm this on iPhone; a webbrowser in the background is not allowed any activity from the iOS to save battery.

On Android, the login screen is shown on resume, after some minutes, on iPhone a modal dialog, after a few seconds ("Disconnected from the server. Either your Internet hiccuped or the server restarted")

A hack is provided here: https://coderedirect.com/questions/552737/keep-websocket-alive-in-mobile-safari

Another potential solution via JS is here: https://github.com/socketio/socket.io/issues/2924#issuecomment-297985409

A third option would be to have the websocket automatically retry to reconnect after x seconds with a maximum number of retries.

[Zamiell]

you can download chrome on ios, so end-users should do that

[DrAnax]

This happens for every browser not just safari. iOS terminates the websocket connection when the browser is minimized.

[Zamiell]

https://coderedirect.com/questions/552737/keep-websocket-alive-in-mobile-safari

this link is broken

[Zamiell]

socketio/socket.io#2924 (comment)

this is possible, we'll have to add new code to the connection endpoint that says "this is a reconnection, so don't send all of the extra stuff that we normally send when users first connect", or something along those lines

[DrAnax]

After some thinking I ended up with the following plan:

• A user opens a new page, connects to hanab.live

• The server asks for login credentials

• After successful login, the server creates, stores and sends a personal token

• Client receives and stores the token

• If the player closes the webpage, the token is obviously gone

• If the player minimizes the webpage (such as the case with the iPhone), a websocket disconnection occurs (but the client still has the token)

• Upon resume, the client tries to reconnect, normally and sends the token

• The server compares the token sent with the one stored (if any). If they match the server considers the player logged in and sends fresh information about its current state (games running, users logged in etc)

• If the token comparison fails, the server asks again for login credentials.

Additionally, the tokens could (should?) invalidate for some time (ie 1 hour)

I'd like to hear your thoughts about it.

[Zamiell]

i dont see what the point of a token is in this scheme. you can remove the token and just have the client send a get request to /ws?reconnect

[DrAnax]

Unless I'm mistaken, since the websocket is closed, the session no longer exists on the server. How would the server be able to identify the reconnection? If there's no token, couldn't anyone, in theory, reconnect by the same user name?

[Zamiell]

the server (already) identifies all websocket connections via cookie, same as every other website