Hacker News new | ask | show | jobs
by dmitrygr 2661 days ago
It is worth noting that this will use a noticeable amount of power more than Google cloud messaging. The basic idea of how is works is about the same, but the devil is in the details. If you look at an idle connection over LTE, you will notice that after a while your carrier will close it. You need keepalives. If you look at the connection for Google cloud messaging, you might notice that it needs much fewer keep alives than YOU need to keep your connection alive. This means fewer wakes from sleep mode and lower power.
3 comments

Not only that, but for many manufacturers this will straight up either not work after the app has been in the background for some (not long) time, or will deliver (that is, app will be able to connect and receive) push notifications with significant delay. Sadly, most reliable way I know to trigger push notifications when app is closed is using FCM - I'd love hear if there's an alternative, though.
Doze mode nukes network connections that are not FCM.
In my experience it's not bad enough to worry about.

I have:

- Signal - Whatsapp - Etesync - Conversations.im - Syncthing

all whitelisted from battery optimisation, and I've not noticed any huge drain (I expected it to be unusable and have to go back to google play services or micro-g).

Signal uses gcm to push to the phone thus waking it so it can download any messages. Not sure about the others though.
If you don't have Google Play Services, it doesn't use GCM.
Is that because carriers have put GCM/FCM on some sort of white-list?
Probably because GCM/FCM has been very well optimized.
While it's likely true, GCM/FCM is handled by Google Play Services, which is whitelisted and has I believe system-level permissions. It has less restrictions than a regular app exempt from battery optimisations, as it's supposed to be the only app that needs to run in order to coordinate things like push messages or location updates across all apps on the device

edit: I missed that the original post was talking about keep-alives and you were probably referring to them. But how app-level optimisations can help with keep-alives?

TCP connection can be open and idle for hours without keep alives. This can easily be configured with kernel parameters:

https://www.tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepaliv...

I suspect the hard bit for normal apps is keeping the app active on the device while it is in the background. Google has their FCM receiver running as a low level service so can make sure it is always running.

You can configure it locally in your kernel, but your ISP will most likely close your connections for you, especially if you're behind a CGNAT.
Even if you have native IPv6, some carriers do connection tracking anyway to prevent random port scans from the internet waking up your phone or trying various exploits.