Been Interrupted lately?
by Christoffer Andersson
One part of this column will be describing different aspects of wireless technologies and another will focus on how these properties impact the applications. One of the most important parts of wireless, and one that will be there even in the most advanced systems of the future, is temporary loss of connection, interruptions. As we get mobile we get more freedom, but we will also have to expect that the radio waves cannot reach us everywhere. The initial scenario pictures how this can affect us all, if we are not aware of how to overcome the potential difficulties.
Graham P. RichardSon is a typical wireless data user. This sunny day in March, 2001, he is on his way to a well deserved vacation from his busy Silicon Valley job. He’s going with his wife to Las Vegas, and she drives the car and lets him finish some work on his laptop on the way. Graham’s laptop is connected to the Pacific Bell GPRS network, and he can do the things he does on the corporate LAN, wirelessly. So, as a salesman he’s just reporting in the latest sales and synchronizing with the server. But then the car is closing in on a part of the Nevada desert where there is not yet any coverage. As the GPRS modem loses connection for a while, the application freezes in wait for responses from the server, only showing an hourglass on the screen. Graham can’t cancel the task(the application won’t let him) and when he comes back into coverage, the application does not understand that it can once again reach the server. Graham has to reboot his computer to fix this, and lots of his input(one week of sales figures) to the application is lost.
This is something that not only can, but will happen if application developers do not have the properties of the wireless environment in mind when designing the applications. The issue is somewhat complicated, as there are numerous things that can prevent an application from reaching its server, apart from the many ways the radio conditions can affect it. Depending on what the condition is, the application might have some access to information about the current status of the network. Here I will, however, focus on generic ways of making the applications work well even when the wireless environment is being difficult.
The first wave of Mobile Internet will consist of mainly two things:
- WAP-like applications
- Applications that let the users to what they are doing on their PC’s today, wirelessly.
The second category is the one that is really at risk when it comes to interruptions and other properties that are typical for wireless network, but rare on the fixed Internet of today. After all, when did you last travel through a tunnel with your desktop PC? Even if you would (don’t ask me why/how), it is unlikely that it would affect the connection to the Internet. With wireless, it’s a totally different story. Even with extensive build-out of the networks you will, now and in the future, experience periods when your device cannot reach a server. WAP has built-in mechanisms to handle these things (WTP , suspend/resume etc), but even though WAP will be the mass market access technology in a foreseeable future, there will be other applications as well. As the ‘always online’ functionality becomes pervasive, more and more laptops will be constantly connected to the Net, enabling us to run whatever we are used to in the home/office environment on the go.
So, why do we get into trouble with interruptions and how can we get around it when not using WAP? Let’s start with looking at what happens when an application encounters an interruption. A client side task (in an application) that needs input/interaction with the server/Internet end will send a request and await an answer. In modern operating systems these requests are commonly implemented by separate threads, so that one request does not hog the entire application (or worse, the entire OS). You can, however, not just rely on the OS to solve the problem for you, but you must always think: What happens if it takes 30 seconds to get a response or if I don’t get a response at all? Also, it is crucial to have a feeling for how threads or Remote Procedure Calls are handled in the platform you have chosen. It is not an incredible hazard to overcome, but if your application, and maybe also the OS, has been designed for Internet access where interruptions are very uncommon, you will have to be careful.
Overcoming this problem is mainly done in two ways:
- Perceived performance
Some Operating Systems do not have concurrent threads, like Palm OS, but overcomes this by the implementation of a powerful mechanism by which the user can stop a transaction (request/response) without killing the entire application. If the user feels that he/she is in control, waiting for a delayed response is not too painful. It becomes a hassle, however, when you do not now when and if the application will recover, and you have no means to interfere. A successful application appreciates and utilizes the possibilities of having mobile, constant access to information, but knows the limitations of ‘constant’. If you know that there is a risk that the response will be delayed, will you put the entire application on hold while waiting?
The second remedy for loss of connection is to keep the user not only in control, but also informed. Compare watching your screen saying ‘Fetching your valuable data, 15 seconds to go’ or watching an hourglass. If the users know that progress is made, or get some indication why there is a delay/halt, he/she is much more likely to put up with it. Then combining this information with the previously described control, the screen will say ‘ Fetching data, currently slow progress the last 20 seconds. Wait some more or click Retry or Cancel.’ Still not good news, but the user is empowered and less likely to curse your application and rebooting the computer.
So, the application you are developing for use in a wireless environment will experience interruptions. Are you prepared for it?
Don’t hesitate to drop me a line with suggestions and comments (responses may be slow sometimes, though, due to the huge amount of incoming mails). If you are in the process of developing wireless applications, make sure to sign up as a member at