Closed Bug 858311 Opened 7 years ago Closed 7 years ago
Push: Investigate variable keep-alive and battery life trade-off on mobile devices .
SimplePush requires an always on WebSocket over TCP connection. With TCP Keep-Alive periods exceedingly long, the implementation currently relies on a fixed websocket ping/pong interval (Bug 855906). This interval has to be a compromise between battery life and 'responsiveness' of the push. Since SimplePush is meant to be used by WebRTC for incoming calls, ideally it should detect socket failure quickly and try to reconnect. Factors to consider: - According to mmayo, the Android kernel seems to consult netstat tables for TCP connections and select CPU powerstates based on that. Is this true of the B2G kernel as well? In that case, a comparison of keeping a WebSocket open vs. watching on a UDP socket is required. - If no UDP is available and we're forced to keep WebSocket up, what is a good keep-alive interval, which detects dropped connections within a few minutes? The few minute requirement exists for applications like IM and webRTC calls which need to be soft real-time. A push notification received 30 minutes later is not very useful. - Select a good strategy for varying this interval over time, based on network condition statistics. - Rather than have a keep-alive, would it be a better strategy to simply drop and re-establish the connection every few minutes, particularly when the screen is switch off and the user is not interacting with the device. This would be backed by the alarms API and allow the processor to shut off for a while. Feedback is appreciated!
I suggest lowering the "timely-ness" of PN when the battery level lowers, e. g. below 30% reconnect every 3 min, below 10% reconnect every 5 min. Above 80% and when loading while above 50%, use Websocket keep-alive of 30s. Or something like that.
In this talk (I can't recall the minute, sorry), GCM developer says that they are using a ping of 28 minutes to keep the connection open, but using adaptative algorithms for different mobile networks. 30 seconds is too low. Device will eat a lot of battery (changing from idle state of the radio modem, to dedicated channel, back to idle, back to dedicated…).  https://www.youtube.com/watch?v=YoaP6hcDctM
The numbers I posted where just for illustration purposes. However, changing the connection type and interval depending on the network type is another great idea!
Component: General → DOM: Push Notifications
Product: Boot2Gecko → Core
Version: unspecified → Trunk
Adaptive ping should obviate this problem for the most part.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 894879
You need to log in before you can comment on or make changes to this bug.