[Feature] Mobile connection handling

[Tlancaalek]

I know this isn’t really one of the original goals, but it’s becoming clear that there are individuals attempting to use Wolfery in a mobile-first or mobile-only use case, and mobile being what it is, this means there are frequent disconnections. For those using Wolfery like this, it’s not immediately obvious what the implications are unless their screen sleeps for sufficiently long that they’re sent home and have to travel back to the park.

For others present, however, this is beginning to turn Station Park into The Reconnection Show.

There are some obvious benefits to immediately reacting to a closed websocket for a desktop client; someone closing their browser tab can be as elegantly and swiftly handled as someone closing a Mu* client. In the mobile milieu, however, people tend not to treat browsers the same way as the desktop, and likely can’t, if they want to preserve their battery life. I’m not familiar with what options are available from a web application standpoint, I’m afraid, so I have nothing concrete to suggest, but it might be helpful if there were a way to detect mobile users and attempt to distinguish between closing a tab and another event severing the web socket. . . ?

[Jagrabbit]

Definitely been noticing this issue as well.

I imagine Lek is onto something about detecting what kind of disconnect is occurring and seeing if we add a new type of filter and/or maybe a toggle that can be applied by area owners to rooms which reduces connection spam?

[Accipiter]

I like the way you think, Lek! There is a bit more to it though.

How auto-sleep works

Actually, auto-sleep is not at all effected by the WebSocket connection/disconnection, nor how active the character is (!?). They are kept awake solely by the client periodically sending a ping call for each awake character. This is either sent through the WebSocket connection, or through an HTTP call.

If the server hasn’t received a ping within 5 min from waking up/last ping, the character will be put to sleep.

How pings are sent

Pings are sent every 3:rd minute. Initially I sent the pings over WebSocket. But this caused issues on mobile devices, as we are at mercy of the OS which has a tendency to quickly disconnect WebSocket connections or stop executing Javascript just to save battery and network traffic when the page is not showing.

To try to counter-act this, the pinging is now done from a Web worker (a process running on a separate thread), which sends pings over HTTP instead. That has worked better, but I think Android/IOS also stops running Web Workers eventually. I haven’t found any info about mobile browser’s exact behavior on this.

There is also something similar called Service worker, which mobile OS might be more generous towards. I could check if that could be used instead.

Sleep on closed tab

The pinging has another purpose than just keeping characters awake; plausible deniability when it comes to which alts you control.

If we were to put all your characters asleep when closing the tab, it would be easy to guess your alts as they all fall asleep at the same time. This is also the reason why I run separate pings on each character, instead of just pinging the player; if you get disconnected, your characters will fall asleep at different time intervals, making it less obvious that you controlled them all.

Park issues

The park dwellers in question notice this for sure; they must click themselves Awake every single time it happens. They are not automatically woken up when reconnecting (as it has nothing to do with connections).

But I must check why they get put to sleep so quickly. It is almost as if the pinging doesn’t work at all for them, causing them to fall asleep directly 5 min after waking up.

Maybe their browser doesn’t support Web Workers?

[Xetem]

This may be a bit of an overkill solution for the problem, but would turning the site into a PWA, hybrid web app, or other type of webview app for mobile devices by any means mitigate this? If the browsers are having issues closing connections not meant to be closed, would an app sandboxed separately from the browser have the same limitations?

[Accipiter]

Turning it into a PWA is probably the most plausible long-term solution to avoid these problems.
(What is PWA? Basically creating a “normal” mobile app based on the web client.)

Then the client can run background services that keeps the pinging going.

[Xetem]

A PWA is a web app that doesn’t need to be containerized as an app but can be treated as one (basically just a mobile chrome window without the chrome overlay). Looking a bit more into them, I think an eventual feature set of a theoretical wolfery app would quickly outgrow a PWA, but a hybrid web app may work.

Basically, a PWA is a bit of javascript you add to the client that tells mobile phones they can “download” it as an app, but it’s really just using the built in (or maybe just the default) browser. A hybrid web app takes the web app and packages it together in a wrapper that’s separate from the main browser.

I’ve done a little bit of mobile app dev, but not really in this realm. Mostly from-scratch projects and what not. But it could be cool to get in to.

[Xetem]

One thing that I will add to bring this topic back to light, is that disconnects from mobile sleeping does greaten the risk of alt-leaking, as it seems that alt characters are going to sleep at the exact same (or close enough) time as one another when this whole mobile disconnect thing happens.