In push notification mechanisms, like Apple's Push Notification Service, they use persistent IP connections.
My question is, how does employing persistent connections save battery and bandwidth of a device?
I am under the impression that since the connection is persistent, then the device always uses the WiFi or 3G/LTE radio.
I know that through persistent connections, you will not waste bandwidth by not asking the server for changes when there is none, and instead the server will "push" to you these changes. But, I don't see how that preserves battery and bandwidth (since you have an always-on connection to the server).
A similar question can be found here:
How does Android C2DM improve bandwidth useage?
but I think the answers are not sufficient.
The way that it preserves battery life and bandwidth usage is a little indirect. The savings come in the form of having one service maintaining a persistent connection rather than every application on your device continually creating/destroying connections and continually using bandwidth.
For instance, if you have Facebook, Instagram, and Twitter apps on your phone, in order to keep everything up to date, you would have three apps polling servers continually for changes.
The solution is to have one service listening for incoming connections and having that service notify the individual application that there are updates.
First you must have into account the state machine implemented by devices to control the power consumption due to network communication. You can see it here
After reading that you will see that, as Adam said, creating connections is very bad for you battery-life and polling is about creating/destroying connections.
Therefore, C2DM avoids creating connections to improve power consumption. In the end, the saving is due to:
- A persistent connection doesn't mean that the device is always in full-power state. It only means that the connection is not closed and then the server can send messages to the client.
- C2DM delivers messages with different mechanisms as you can read in GCM Advanced Topics. Hence, it can be configured to deliver messages only when the devices is already in full-power state
- The last factor is how GCM delivers messages to idle devices. It is quite unclear in the official documentation and I think that the source code for Google Play Service is not available. Nonetheless, you can get some clues with the following answer here. The first commentary seems useful.
There is a point I am not sure: I don't know how they keep the connection alive at low-level. That's the piece I am missing. You can read Android C2DM slide 15 for some explanation. It seems that they provide some kind of clever handling of the state machine.
