Hacker News Reader

Comment by yegle | Hacker News Reader

Is it possible for every app developer to stop using FCM? Yes, in China.

The result is a chaotic market. App devs will have to use multiple push machinism for different device: on Huawei phones, Huawei's own push service is the most reliable; on other phones, you might want use SDKs from Tencent/Baidu/Alibaba so their app (Wechat/Baidu search/Taobao/Alipay) can "wake up" your app to receive push. Battery life become miserable, push become unreliable. It's to a point where the government start "regulating" the market (the Unified Push Alliance, http://www.chinaupa.com, is lead by CAICT, a think tank of Gov of China).

View on HN

But do we really need "push providers"? The problem is (IMHO) that app developers don't know how to use the connection efficiently causing the radio to wake up constantly (IDLE socket connection has very low battery impact). Instead of pushing every darn detail queue less important ones and send them out when something more important arrives; your client app can signal the server, that app is in the background (or phone is going to sleep) to send less frequent updates. But - companies will abuse everything they can to notify users about absolutely everything. Currently I'm running phone without google play services and it works just fine (with exception of Viber, which can't deliver messages correctly without push services, but it's not that important for me).

As soon as you are maintaining multiple connections, battery life gets worse.

If you don't have a push provider mediating the many apps trying to get notifications, you end up in a tragedy of the commons scenario, where every single app will try to implement its own push service and will prioritize its own push service, quickly resulting in a race to the bottom where the device is constantly connecting to a different push service, draining battery and exhausting your data connection.

It isn't very different from preemptive/cooperative multitasking.

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?

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.

OK, dumb question - do all applications need push communication? Apart from IMs (and maybe e-mail) I would say that everything else should rather do pull than push.

And Google is doing virtually that, with enforcing push via their services and controlling Doze, making some apps receiving notifications with (sometimes significant) delay.

What's more, I would argue that in quite a lot of cases NOT having immediate push notification could work wonders on our attention span, but this is slightly less technical problem :-)

We need the core operating system to provide a push provider that we trust. Do we trust Google to act as a push provider?

Reply on news.ycombinator.com