Re-Thinking Push & How We Build The Mobile Internet

by dan on September 22, 2011 in Under The Hood

Everybody remembers the wow factor of using their first BlackBerry and emails showing up on the device seconds before it showed up in Outlook.  They nailed push – super fast email delivery and killer user experience because of it.  Unfortunately, there is a huge downside to how BlackBerry does push.  Integration is not included.  In order to make BlackBerry’s vaunted push technology work, carriers have to integrate to BlackBerry data centers via VPNs or expensive leased lines.

The big hard technical problem of push is that most carriers don’t allow an outside server on the public internet to connect to a phone and send data to the phone.  The phone can always go ask a server for new data (polling), but servers aren’t usually allowed to initiate a session to the device itself.

So there have been a variety of tactics companies have tried to use to solve this.

A few years back, the trendy mechanism du jour was SMS wake-ups. When you got a new email for instance, a server would send a text to the device.  The device would say “hey thats a system SMS.  Lets startup the email app and go check for new mails”.   Huge problem, everytime you got an email, you were basically double charged – you paid for an SMS + the data for the email.  Consumers puked when they saw a long list of SMSs on their bills, so this kind of went away (carriers also didn’t love wasting capacity on their precious SMS network for “push”).

The newer trend has been HTTP.  The internet standards have evolved to support two push mechanisms for HTTP – Comet (the Bayeux protocol) as well as websockets.  HTTP is a great choice, port 80 is always open, there are tons of protocol stacks in any given programming language available, phones often support it natively, you can re-use proven technology like Apache web servers to build applications, and so on and so forth.  Its a great innovation for mobile devices.  Android’s cloud to device messaging framework relies heavily on it for instance.

The problem with HTTP and/or TCP is that it is heavy.  It introduces a ton of “protocol overhead” that is not required in the mobile world.  This means that there is a ton of wasteful data that consumers are paying for in their monthly bill.  You see this in iPhone and Android today, tons of wasted MB usage each and every month for protocol overhead and poorly designed applications.

So here at Peek, we put our big cloud brains to solving this problem.  How could you provide push that met this real world challenge:

1.  Very little protocol overhead

2.  No integration with carrier required.

3.  Not only “no integration” but works on all mobile networks.  Also not possible for carrier to “shut it down” or “block the service”.

4.  Works reliably in 2G environments

5.  Fast, fast, fast.

6.  Helped the battle for long battery life.

Previously, we had a version of push working that did everything but #3 above.  It worked in about 40-60% of networks globally.

Well, after some extreme engineering, we now have a version of push that will work basically on any phone, any where.  And get this, in our field testing we are seeing it to be 96% lighter than HTTP variants.  96%!!!!  Imagine the impact on battery!  Imagine the impact on performance/usability since the cpu & modem aren’t churning away processing wasted overhead!  Better yet, imagine the impact on a customer’s bill!  And so far it has worked on every network we have tested it on.

This is an important lesson for makers of applications everywhere.  From a pure development perspective, its usually easiest to re-use well known technologies and protocols.  But its not always the best answer for the software you are building.  Be thoughtful and creative in your engineering and it’ll pay off dividends for those who use your application.   Here are a few pointers:

-Use UDP.   Its so fast and light.  Simple retry algorithms can give you a high degree of reliability.

-Compression.  Did you know you can use your own dictionary to make it more efficient?  For us, we had an intern spend about two days creating a custom dictionary for zlib based on word frequency in the email data we saw.  This resulted in about a 10% improvement.  10% reduction in data being sent over the wire.

-XML, binarize it (lookup wbxml algorithms)

-JSON, binarize it (lookup BISON and other alternatives)

-HTTP, strip un-needed headers, like the browser identifier

My biggest pet peeve in my world is picking up a “push” email application to only find out it is on a 15s poller.  What!?!?!   Polling every 15 seconds!!   I don’t know about you all, but I prefer my battery life to be counted in days, not minutes.  So please engineers, put some time and energy into tackling the hard problems of your application.