Compartilhar via

Putting PUSH into Perspective

  • Artigo

I found myself in Breckenridge, CO over Super Bowl weekend enjoying an amazing mixture of skiing, food, and well-- a really awesome game.  This was our annual "guys" ski weekend -- no shopping, no whining, no pony rides.  Ski until you drop.  Eat, watch some football, and ski again.  Most of us have desk jobs, so after 6 hours we're all sore enough to die, but nobody admits it -- because that would be unmanly.  Whoohoo!  I feel great... ski on!!!!!! (OMG I'm dying... I'm 10 years younger than he is, surely he will die first ... then we can call in the paramedics and end this madness).  Ah, Good times.

Anyway, I was soaring up the Rocky Mountain Super Chair and taking note of the high-speed lift mechanics and I couldn't help but geek out a bit.  This thing is not unlike a communication channel.  On one side, we've got skiers zipping up the lift to the top of the mountain and on the other side, empty chairs coming back down -- like an ack that the payload has been delivered.  So here I am, attached to a circular cable system that was clearly moving along with great momentum delivering chairs.  Is the top pulling or is the bottom pushing? Probably doesn't matter does it.

PUSH vs. PULL (POLL)
This is a debate that comes up a lot with Windows Mobile.  Developers struggle with it designing architectures where mobile clients need to be notified of new data.  They will ask, "how can I push notifications to  mobile clients".  I'll often suggest they have the client poll for updates and they look at me as if I've suggested they wear bell bottoms.  SMS may be okay for some tasks, but there can be a cost and reliability issues.  If you are in the "I want it now" group, then logic says that new server data should be pushed to the clients right? 

IT guys are not immune to this either.  They get dragged into the competitive PUSH email discussion... the idea that pushing is indeed superior which fuels the debate.

Hmmm.... I'm a sucker for this discussion.  My opinion may only be worth 2 cents or so, but that's why we have blogs.

He started it!
Once the line of communication is open, push or pull has little relevance.  Someone is listening and someone is talking, but the data is moving in both directions.  PUSH is about who initiates the conversation.  

The challenges of push
To truly do push, you need a mechanism on all your clients to constantly "listen".  Your server also has to be able to locate and contact all your clients.  This also involves error recovery when a network connection is broken or client becomes unreachable for other reasons (loss of power, no signal, etc.).  It's a lot harder to do than one might think.  It can put a huge amount of overhead on a server to simple manage client connections -- above an beyond actually trying to transfer the data.  This also become a big problem when you don't exist inside a controlled network where there may be any number of layers of NAT going on. 

It sounds like a good idea, but asking a server to initiate communication with a large number of mobile clients -- across networks outside your control is well... nearly impossible. 

How polling is your friend
Okay, polling may be old school but the truth is that many applications use variations of polling and you probably never noticed it.  When done well, then implementation is transparent and you just get timely updates. Examples?
* Desktop Outlook and yes, even Outlook Web Access
* Most RSS readers
* Web pages that use AJAX or refresh tags to update content
* Most client/server apps
* and yes... PUSH email on Windows Mobile

Did he say PUSH email is polling?  Kind of... our implementation of "PUSH" email is actually initiated by the client so in a way, it is.  Remember, once the communication channel is established, it's irrelevant whether we're talking PUSH or POLL, but the fact is -- it's a lot easier for a mobile device to initiate and manage the communication channel.  It's more network friendly and also easier to secure.  The important thing is that new data is readily available when you need it.

With any polling architecture, the question is "how often".  With mobile devices this answer is a balance between battery life and user requirements.  PUSH email is cool, but scheduled sync adds battery life to your device is you don't need updates right away. 

If you have a very controlled network and need near real-time updates on your client, then maybe a true PUSH architecture makes sense.  For most apps, it doesn't.  Polling is your friend and if done well, all your users notice is that the information they need is there when they want it.  It also gives your device a chance to make better use of its battery in between poll intervals-- especially over a network connection that has a high price on your battery (e.g. - there is a reason we don't do PUSH email over WiFi).

The important thing is that data is there when you need it and we've got a lot of cool options to make it all work.

I'll do some future posts on some of the ways to build sync architectures with Windows Mobile as this is going to be a hot topic in the months to come. 

Cheers,
Reed

Comments