Hacker News Reader

Comment by iad | Hacker News Reader

Why can't the device just chose a single wake schedule and communicate that to each push provider? Hopefully UDP can be used so there's no need for any keepalives or handshakes during the wake periods?

Are clocks too unreliable or is there too much NAT because everybody's too lazy to implement IPv6 still?

View on HN

This actually happens on Android (read about Doze mode), but the issue with your approach is that you don't get realtime delivery - only periodic sync. Which is actually less efficient, because the device must wake up on interval, activate the radio and poll for changes.

FCM (and Apple push) run a single keep-alive TCP connection and incoming packets will cause radio and application process wakeup only when necessary.

This change significantly improved Android battery life (remember that HN Apple lovers really loved to bash on Android battery life before this FCM push happened). The fact of the matter is that a lot of developers didn't care one bit about battery life and abused Android background services when there was no need to do so (e.g. schedule periodic wakeups to check for a preset alarm needed once 24 hours) and if we learned anything by this experiment is that you simply can't trust developers to respect users anymore.

Does the 1 tcp connwction notnrequire the radio to wakeup to receive pushes?

It does, but not really periodically - the radio is just listening and not transmitting until a packet comes. Then it wakes up the application processor to handle it.

I guess the question is, if a single listening TCP connection is not a problem because everything can sleep until a packet arrives, what's the problem with multiple apps each opening such a connection?

Increase amount of chatter, more keep alives, problems with NATs (see the other post in this thread) which don't whitelist non-Google/Apple endpoints, etc.

But majorly - it makes little business sense for Google to support that. It can only make Android look worse for little gain to them.

Dev here : you are 100% right that battery life is not optimized for in most cases.

For one it is hard to measure, and many devs don't really know/care about it.

FCM is a boon in this regard. So are the restrictions that Android is adding to background processing. They are technically not that necessary ... except that you can't trust any app not to abuse it, so the new model is so much better.

Also, thanks Google for finally forcing apps to target the last version or so of this OS so they have to adopt all these new optimizations, whether they want to or not.

I think you're describing a pull workflow... which more apps ought to be using, but does fill a different role than pushes.

Other posts answered most of your question, but there is still one point regarding IPv6. IPv6 doesn't solve any of this problem, because the problem isn't actually the connection, but the synchronization between all the apps using push services, the wake state of the device and the radio utilization.

IPv6 would solve a single push service, but with every app deploying its own push service, you get back to the tragedy of the commons problems.

As it has been seen again and again on Android, you absolutely cannot trust app developers to be good citizens and stop running services on background that quickly wipe your battery (not to mention even more shady stuff), and no way you'll be able to trust developers with push services that don't do the same.

If you need proof, just look at China, it is the wild west of push services.

Would it not be possible for an OS to implement a push receiver service with an open port. With IPv6, after registering through an app with a server, the server can just send a UDP packet to the open port? Maybe you could do an "hmac firewall" like in OpenVPN to avoid processing nonsense packets?

> With IPv6, after registering through an app with a server, the server can just send a UDP packet to the open port?

That's your problem, if the radio is off and you're using UDP, the message will simply be lost. You can leave the radio on permanently, but you'll kill the battery.

Reply on news.ycombinator.com