This reminds me of a tool named pwnat by Samy, the myspace hacker.
It is a tool that allows any number of clients behind NATs to communicate with a server behind a separate NAT with no port forwarding no DMZ setup, and no 3rd party involvement. The server does not need to know anything about the clients trying to connect.
> If the ping events come too fast, it can cause some clients to never go into sleep mode. ... It was noted that on an iPad if you left the FastMail webpage open in Safari and put the iPad down ... [t]he screen would stay on, draining the battery very quickly.
Am I reading that right? Safari permits a malicious web page to trivially keep the screen on your iDevice active until the battery is drained, or you navigate away from Safari or the web page?
If I am reading that right, that's a terribad decision on the part of the Safari folks.
I think it's done for the same reason you wouldn't want the screen to go dark while you're watching a video.
I've also experienced "unwanted sleep" while reading lots of text in a browser or other app - having to keep a finger on the screen quickly gets rather annoying. I understand the desire to conserve battery, but I prefer to act in the I will sleep the device when I am done looking at it manner.
I can understand that, but it's totally the wrong way to go about it.
If you want the screen to not sleep, create a "Don't let the screen sleep" call in WebKit and encourage folks to use it. I mean "DPMS powersave toggle" seems to be a better -and easier- feature than "Tell this webpage my physical location".
The apps use OS/platform push for notifications, because the webapp component is asleep at the time. When the app is active, its just the regular webapp, which uses eventsource.
The JMAP spec provides for eventsource and webhooks, but obviously an individual provider can offer more than that via an extension. When we do switch over to JMAP, we'll continue to use our custom method to register platform notifications.
It's not "just" use websockets. These may be intercepted by proxies with connection limits, timeouts or just plain not understanding websockets at all.
You will need to detect this and apply a fallback mechanism.
Which goes back to the point of this post: easy in theory. Much harder in practice.
Where I work we ended up using Microsoft's signalr-library to avoid having to learn and tackle all of these issues ourselves.
Yet we still needed to add some additional Band-Aids around the libraries provided to be able to support all cases we wanted seamlessly.
https://www.zerotier.com/blog/?p=226