This is a great and important project for F-Droid.
The problem is harder than it seems on the surface as idle connections can be terminated by the network operator. There's a paper about this: https://ieeexplore.ieee.org/document/8214213
I guess ultimately one should build a database about phone networks and store measurements of their maximum heartbeat intervals in there so that new connections can use those heartbeat intervals to save battery.
Also ideally the app should send its data via WiFi if available. So it has to detect when a WiFi connection is established and open a connection wia WiFi. Ideally the mobile connection is kept alive though for the case the WiFi proves unreliable. E.g. when I leave my home on foot I get further and further away from the WiFi and there's a short time span where my phone keeps trying to use the WiFi connection even though nothing gets through any more.
Detecting all these edge cases can be tricky. Fortunately the design makes the protocol between the push server and the on-phone app open to iteration and innovation. It's a good design!
If you can build a database, great, but you can probably get by with a device based adaptive ping frequency, reset when connectivity changes.
Start at a 1 second ping, and after each successful ping, double the interval until you get to over a minute. Then add a minute between each ping until you get to 10 minutes, then add ten seconds between each ping. If a connection drops, use the last successful interval for tenish pings, then probe with an additional one second. If the connection drops again while probing, reconnect and wait longer to reprobe. If the first ping failed, then assume the network changed and reprobe from the top.
And yes, you do need to start at one second; I've seen networks with a ten second NAT timeout, which was amazingly disruptive, and thankfully temporary.
Excellent point. So how does Google solve the problem? Do they just coordinate the heartbeat intervals with the carriers, or do they bypass the Internet altogether and use some cell-network-specific push mechanism? If the latter, is this mechanism available to everyone or just partners of the carriers?
> Do they just coordinate the heartbeat intervals with the carriers, or do they bypass the Internet altogether and use some cell-network-specific push mechanism?
IIRC they use the xmpp protocol, so standard TCP over IP. In threads about this topic you often hear claims that Google has special deals with carriers. Whether this is true or not, no idea. I haven't seen any confirmation of this. It would be interesting to conduct measurements whether FCM sends less frequent heartbeat messages than the timeout is for "normal" long lived tcp connections.
In any case, deals or not, I guess Google has built a database as I've mentioned. But I'm only guessing here.
AFAIK these disconnects still happen (my knowledge might be outdated). It would be cool if the phone figures out by the weakening signal + location that it should turn on the data over cell connection.
The problem is harder than it seems on the surface as idle connections can be terminated by the network operator. There's a paper about this: https://ieeexplore.ieee.org/document/8214213
I guess ultimately one should build a database about phone networks and store measurements of their maximum heartbeat intervals in there so that new connections can use those heartbeat intervals to save battery.
Also ideally the app should send its data via WiFi if available. So it has to detect when a WiFi connection is established and open a connection wia WiFi. Ideally the mobile connection is kept alive though for the case the WiFi proves unreliable. E.g. when I leave my home on foot I get further and further away from the WiFi and there's a short time span where my phone keeps trying to use the WiFi connection even though nothing gets through any more.
Detecting all these edge cases can be tricky. Fortunately the design makes the protocol between the push server and the on-phone app open to iteration and innovation. It's a good design!