3 ms·

I've never looked deeply into this notification thing but people seem to conflate saving the battery and having only one notification server. If energy used by

by guerby 6y ago

I've never looked deeply into this notification thing but people seem to conflate saving the battery and having only one notification server. If energy used by firing up the CPU frequency plus the 4G radio to send some packet is the main battery drainer, why not just synchronize the poll of multiple notification servers? The CPU will be waked up, a few data packets will go to a few notification servers, then in the common case of no notification everything goes back to sleep. If it's the network that wakes up the phone when some packets are there (as WiFi energy saving does), if synchronized in time (NTP goog enough) it should also work and be energy efficient. Probably naive, curious about real world measurements in this area :)

kylecordes 6y ago
Technically there is a workable solution somewhere close to what you describe, and it should cost tiny extra power usage vs the fully centralized design. But imagine you are a company running one of the big mobile platforms. You could invest effort in the APIs and OS behavior to do this, and the payoff would be loosening your grip on the ecosystem. Tough to justify to those watching the ROI.
room500 6y ago
Just one issue - there are timers on connections regulating how long a connection can be kept alive before a packet is required. Larger timeouts are better for phones, but require more resources on the servers/networks. Google/Apple work directly with carriers to extend the timeouts for their push services so the phones aren't required to send keepalive packets every 30 seconds to keep the connection alive. Carriers won't be willing to do that for every random server out there. This is just one of many ways these push services are carefully designed/operated to save as much battery life as possible. If you had more than one notification service, battery life would degrade to the worst performing one (the radio would be forced to wake up to keep every notification service alive... Even if the Google one could go minutes between the keepalive packets) (Another is the way Google batches low priority notifications... Sending a push message won't immediately wake up a phone - it delays to try to batch as many messages as possible. This scheme breaks down if messages aren't all routed through a single server)

by guerby 6y ago

kylecordes 6y ago

Technically there is a workable solution somewhere close to what you describe, and it should cost tiny extra power usage vs the fully centralized design. But imagine you are a company running one of the big mobile platforms. You could invest effort in the APIs and OS behavior to do this, and the payoff would be loosening your grip on the ecosystem. Tough to justify to those watching the ROI.

room500 6y ago

Just one issue - there are timers on connections regulating how long a connection can be kept alive before a packet is required. Larger timeouts are better for phones, but require more resources on the servers/networks. Google/Apple work directly with carriers to extend the timeouts for their push services so the phones aren't required to send keepalive packets every 30 seconds to keep the connection alive. Carriers won't be willing to do that for every random server out there. This is just one of many ways these push services are carefully designed/operated to save as much battery life as possible. If you had more than one notification service, battery life would degrade to the worst performing one (the radio would be forced to wake up to keep every notification service alive... Even if the Google one could go minutes between the keepalive packets) (Another is the way Google batches low priority notifications... Sending a push message won't immediately wake up a phone - it delays to try to batch as many messages as possible. This scheme breaks down if messages aren't all routed through a single server)