David Yach From RIM: Slams 3G , applying wireless thoughts to web development

So we went to a presentation last week given by David Yach @ RIM - makers of the Blackberry. We weren't sure what to expect - David gave an excellent talk about wireless technologies in general. He drove home that the following 3 points have to be taken into consideration when working with wireless devices - three limiting factors:

Spectrum - there is only so much, and it costs money to use.

Thermodynamics - processing takes power, and generates heat.

Battery Life - improving much more slowly than Moores law.

These 3 factors drive a spike through the heart of most 3G devices. Battery life constrains a device to being capable of transmiting a fixed # of packets and/or receiving a fixed # of packets (transmitting taking 10x the power as receiving) - and we're not talking huge numbers here - we're talking about a device being limited to receiving 5000 packets of data.

Spectrum is a scare resource as well. When bandwidth is being discussed, it is the peak bandwidth, if your device is the only device using all available spectrum - in a crowded area, you are sharing spectrum with multiple devices, and network performance would be reduced. More base stations could be created to spread the load, but the cost is N-squared. (1 device covering a 10 kilometer by 10 kilometer area , to be replaced with devices covering 1k x 1k, requires ~ 100 devices).

Thermodynamics referred to the fact that an electronic device doing things gave off heat, and you don't want to be burning people using your device.

RIM is big on their push paradigm - rather than having their devices continually asking "Got anything for me?", and getting a reply "Nope" - they just listen every so often, and eventually get a message "Hey I've got something for you..." - a device that doesn't support push, that queries every 5 minutes, will send 12 packets an hour x 24 hrs = 250 packets in a day (or about 5% of the total battery life), and be getting nothing back for the most part.

He discussed various problems with communication - that request/response can add a fair bit of overhead to a wireless device - that if I was watching a stock price from a webpage, that webpage contains a large amount of fluff that might be getting re-transmitted over and over, when really I just want a couple of bytes of data representing the current price.

There were 2 key points that make wireless application development difficult:

1) Devices aren't always reachable - (like unplugging the ethernet connection from your PC at random every couple of minutes. How do your network apps behave?) I can be in an elevator, a basement, out of range, out of country, etc.

2) The cost of bandwidth for an enterprise can be a huge factor. Suppose my empty "anything for me?" queries cost 2.5 cents a day, multiply that by my 10,000 employees times 365 business days, means that I'm spending $250 x 300 = $75000 / year on empty "anything for me" messages being sent -- Then consider a real application to retrieve pricing in real time, and you could be using serious amounts of bandwidth, and the pricing app ends up with bandwidth costs in the millions.

We can take these two lessons, and apply them to our web application development in the following ways:

1) How does our web application handle failure - if a network connection goes away, or a server running our application reboots (and the user's server side session is lost) - what happens if the user is in the middle of filling out a form.

2) Take advantage of browser caching - ensure that you are setting the cache header entries correctly - often web applications just tell the browser not to cache a page, and leave it at that. If I tell the browser not to cache some javascript, an image, or whatever that gets reloaded every page I view, and request this 100 times in a day (and there are 1000 users doing this through-out the day) we could be talking about unnecessarily retransmiting 10K x 100 x 1000 = 1,000,000K = 1,000M = 1 Gig of network traffic (per day) that I could have avoided.

3) We can take advantage of new technologies (such as AJAX) to retrieve only the pieces of data that change - not requiring the user to wait while 100K of fluff getting loaded every time they refresh their display to see if just a few bytes of data are changing.

4) Compression - We recently implemented gzip encoding in the web server that is built into our products (Alcea Fast BugTrack and Alcea Fast IssueTrack). We have reduced traffic and output by a factor > 10 in most cases. Dial-up users or users with distant remote connections will see page refreshes in under a second vs. up to 10 seconds (just to transmit the summary data for 100 issues within our system).

In other news, I got my hands on the new RIM 7100. After listening to the presentation and talking with some of the other RIM technical folks, I went out and got a 7100 for myself. I'm quite happy with it - as a phone it sounds great, feels great - and I am getting used to the new typing technology.

I had an old RIM 950 pager back in 1998 and used it extensively while I was roaming around. A couple of years later, I was pretty much stationary at a PC, and didn't require roaming emailing capability.

However after the presentation, realized that if I can process a few more email while I'm waiting for an elevator or standing in a line waiting for coffee, that I'll have that much more free time when I get home in the evening. This is really what all technology should be aiming to achieve (not technology for the sake of technology, but technology for the sake of improving my lifestyle, by giving me more free time, increasing my productivity, etc). These are messages that really resonated with us in terms of our products - By making products easier to setup, configure and use, learn and run on a day to day basis that we're actually making peoples lives better by giving them time to do things that they enjoy (rather than being chained to a computer all day).