There’s a thought provoking article by Andrew Seybold on how he thinks pushing information to phones will help phone battery life and make applications more acceptable to users.
"Today’s breed of smart applications knows what information you want and periodically wakes up your device to send a query out over the data channel to see if the information has changed. This works well and is certainly better than having to use a browser, but it will be even better when these types of applications work the way email does today-that is, when messages are pushed to you across the network only when the information changes."
"… if you set them up to check your information too frequently, you can run your battery down pretty quickly"
"…but it will be even better when these types of applications work the way email does today-that is, when messages are pushed to you across the network only when the information changes."
Technically, what exactly is the ‘push’ Andrew is talking about? Are such technologies really available?
A server can’t usually start communication (open a TCP connection on a particular port) to a phone because mobile devices do not have registered IP addresses. Instead they are connected through a NAT gateway that prevents direct connections. This means that use of a server initiated TCP connection isn’t usually workable.
Many email/notification solutions don’t use true push where the server instigates the communication. Most push solutions are actually pseudo-pull. They rely on the phone starting a long running connection during which the server might send some information. Here are some examples…
- IMAP IDLE. This isn’t actually a push request but instead is a long connection with the server.
- Microsoft DirectPush. This is a long https connection.
- iPhone Push Notification service. This is a long running connection.
The problem with long running IP connections is that have to be kept going. They have to be occasionally re-freshed or re-started and long-lasting connections are less able to be load balanced or scaled. Hence, the problem with Apple delaying (having to re-architect) their Push Notification service to cater for a very large number of connections. Apple really are at the leading edge of scaling large numbers of long connections to the server.
One true push solution is SMS but it’s not really designed for this purpose and applications based on this tend not to be elegant and are expensive for the end user.
The only true real push solution is BlackBerry. The BlackBerry network has a radio signalling layer on top of the cellular network that does not require an always on TCP connection. RIM has a proprietary architecture that’s sets it at an advantage. I could be wrong but I think it’s very unlikely similar technologies will appear because they need to tie-in so intimately with carrier networks.
Thinking further ahead, I am not sure push (as opposed to pull) will help next generation phones where IM and Twitter type apps need very regular updates. Using many push apps at the same time might have the same (battery) effect as having all of them running an polling (pulling from) servers. i.e. there’s nearly always a connection doing something. I suppose you would have to take measurements to prove this.
What might be more interesting is looking at aggregated communication schemes where multiple services share a push or pull message and the corresponding IP connection to the server. Obviously Google and Apple are well placed to do this where people subscribe to a multiple of their services or applications based on their technologies.