Development | .NET Compact Framework

Determing Network Connectivity
Written by W.G. Ryan  [author's bio]  [read 27421 times]
Edited by Derek

   

Page 1 

Determing Network Connectivity

Barely a week goes by without a post or 10 on the various Compact Framework Newsgroups where someone doesn't inquire about network connectivity. Some people are trying to use the full SQL Client namespace which isn't very useful if you aren't connected to a network. Other's ask about invoking a web service in an effort to pull back some data, something else that's kind of sucky if you don't have a network connection. Then there are folks who are trying to move files back and forth from their device to the desktop, and want to have the ability to immediately detect when the device is cradled and show some sort of notification. All of these are fairly common tasks when dealing with PDA development and all of them share one thing in common, namely, the need to determine whether or not the device is cradled or not (I know, techincally you can grab data from a Web Service via GRPS, but assuming one doesn't, it's still a valid thing to inquire about.)

The following code snippet in Devbuzz's Code Snippets section shows how one might go about accomplishing this task:

 

Public Shared Function GotInternet() As Boolean    Dim req As HttpWebRequest    Dim res As HttpWebResponse    Try req = CType(WebRequest.Create("http://www.devbuzz.com"), HttpWebRequest)    res = CType(req.GetResponse(), HttpWebResponse) req.Abort()    If res.StatusCode = HttpStatusCode.OK Then       GotInternet = True    End If   Catch weberrt As WebException      GotInternet = False   Catch except As Exception     GotInternet = False    End Try End Function

This solution is easy to use, easy to understand, and in most instance gets the job done. All you'd need to do is intermittently call this function via a timer or low priority background thread and you could keep track of whether or not you're connected thereby giving you app the ability to respond accordingly. (Whether or not you should opt for a multi-threaded solution over a timer based one is a whole different can of worms but the logic is the same with either approach).

But there some shortcomings to this approach. For one thing, we've got to remember that PDA's at their present state aren't exactly oozing resources like RAM and processor speed. So, if you polled frequently enough, you'd invariably raise quite a few exceptions when the device wasn't cradled and exceptions aren't the cheapest thing in the world. But a more serious issue might arise if you were using a Smart Phone or device that might need to call into the network at each request. As you can see, that could get ugly quite quickly. But what if you lost your internet connection ? If you have my cable modem service company (who's name coincidentally rhymes with BombBlast) that's a pretty common scenario. You'd end up with False Positives. If someone pulled out the desktop machine's network cable, it'd report a false positive as well (I know, if the desktop wasn't connected to the network then you don't actually have "Network Connectivity" but what we're ultimately trying to determine here is whether or not we are cradled. If our goal was solely to ascertain whether or not we had actual Internet Connectivity, then the approach I'm about to recommend won't work). Finally the web site in question might be down for maintenance or whatever else. In each instance, your device would think it wasn't cradled even though it was.

So how do you resolve this? In order to understand what we're about to do, you'll need some background info on what goes on behind the scenes when you 'cradle' the device. Upon cradling the device, the cradle and desktop machine morph into a new role, that of a network gateway. Now the device's IP Address is going to be something other than Home aka 127.0.0.1. This provides you the ability to infer (accurately) if the device is cradled by virtue of its IP Address. So any instance where IP Address != 127.0.0.1 accurately indicates your device is cradled and any instace where it is, means that it's not.

Now, let me emphasize something here. Just because your IP Address isn't 127.0.0.1 DOESN'T NECESSARILY mean you have internet connectivity. You may or may not, but you can't tell from this alone. However, you can tell from this alone if your device is cradled or not. Secondly, the code snippet above will port over directly to the full framework and you can use it from any desktop app to determine if you can hit the internet or not (provided of course that the web site you are sending requests to is up and running). However, if you use the code below, the logic will break because ActiveSync and the cradle aren't sitting in between your computer and the network but the code WILL compile. The assumption behind the logic no longer holds though and you don't have the benefit of a compiler barking at you to indicate that your logic isn't valid.

With that said, all we need to do is use the System.Net namespace and use DNS to determine the device's IP Address.

VB.NET:

C#

So all we're really doing is using System.Net to determine out IP Address and respond accordingly. The same issue regarding using a timer or a background thread is present here, but that's a whole different matter.

Back to .NET Compact Framework | [Article Index]