How to Monitor Network Connection Status Using .NET* and Web Services

Submit New Article

December 9, 2008 11:00 PM PST


Challenge

Determine whether a system is connected to the network, and monitor its status to determine when it reconnects or disconnects. Although the connection types and speeds vary considerably, a key aspect of traditional Web applications is that a connection is always required. Once the connection is down, the user's Web browser is unable to connect to the Web server, and the Web application remains inoperable until the connection is re-established.

In mobilized software, a connection is used but not always needed. That is, if the connection is severed, the application should still be functional to the highest degree that is reasonably possible.

One technique to accomplish this goal is the use of a client-side database to cache data. Until recently, the idea of running a full-fledged database-management system on a laptop computer would have been unthinkable. Today, the Pentium® M processor provides the necessary muscle to handle SQL Server 2000* or MSDE*.

As the user adds or modifies data, those changes are immediately stored in the local database. If a connection is available, then the client uploads these changes to the server. If the connection is not available, it does not cause a problem. The application periodically monitors the connection, and as soon as it has been reestablished, the changes are uploaded to the server. This functionality occurs in the background. To the user, the application continues to run normally.

Solution

Call the Ping Web Service asynchronously. To determine whether the application is online or offline, the server portion of the application exposes a Ping method. This Web service is one of the simplest Web methods ever created:

[WebMethod]

public void Ping()

{

}

 

The Ping method's purpose is simply to provide a fast, efficient way for clients to determine if they can establish a connection to the server. If the call is successful, the client knows the connection is up. If the call fails, then the client knows it is offline. A try...catch...finally block is used on the client to catch any errors from the call to the Ping method.

Rather than interrupt the user with an annoying message box every time the connection state changes, the status bar is used to indicate whether the application is online or offline. This is another key aspect of the OCC model: users should not be bombarded with error messages indicating that the connection is unavailable, or that the application is no longer working.

In addition to determining whether the application is online or offline, another technical challenge involves varying quality of the connection. Depending on a number of factors, a wireless connection can be especially slow.

For examp le, a call to a Web service might take two seconds if the connection is fast, but 45 seconds if the connection is slow. If the Web service is called synchronously, the user-interface thread will be blocked, and the interface will not paint. To keep the application as responsive as possible, Web services should be called asynchronously.

When a Web service is invoked asynchronously, the call is started on a separate thread. This allows the program to continue executing while waiting for the Web service to complete.

To call the Ping Web service asynchronously, use the BeginPing method, passing in a callback delegate. A callback delegate is a type-safe function pointer that indicates what routine to invoke when the call to the Web method is complete:

System.AsyncCallback myCallback = new AsyncCallback(PingCallback);

pingWebService.BeginPing(myCallback, Connectivity.Online);

 

Then in the callback routine, complete the call to the Web service using the EndPing method:

private void PingCallback(IAsyncResult e)

{

try

{

pingWebService.EndPing(e);

Connectivity.Online = true;

}

catch

{

Connectivity.Online = false;

}

finally

{

this.Invoke(new SetPingStatusDelegate(SetPingStatus),

new object[] {Connectivity.Online, e.AsyncState});

}

}

 

Note that all the code inside of PingCallBack is enclosed within a try...catch...finally exception-handling block. One of the key principles behind the mobilized-software model is that the connection might be lost at any time. Therefore, any call to a Web service should include proper exception handling.

Source

Mobile Reference Model: Power Management and Mobilized Software Initiatives