WiFi Network connectivity status - best method to check if offline?

-
WiFi Network connectivity status - best method to check if offline?

I have an app running on a Winows PC on a warehouse truck, which roams the halls of dairy products.  Some corners of these dark and secluded halls can have iffy WiFi coverage, and I need to have an idea about if I am connected or not - and preferably I'd like to know before I try a database operation and get a time out.

I have a Windows Server on the other end, and I have a running Window Service that can do IP connections.

Q: What method would you use to keep track of the WiFi connection Status?

Comments

  1. Dorin DuminicaDecember 17, 2012 at 7:30 AM

    I'd probably run the queries in a separated thread, if it doesn't return within a reasonable time, just kill the thread.
    Note: didn't gave it too much thought... there are some delphi libs around for wifi management, maybe it's better to test the link status?

    ReplyDelete
  2. Fred AhrensDecember 17, 2012 at 8:01 AM

    You'll find some examples for tracking the WiFi status at http://theroadtodelphi.wordpress.com/2011/10/15/all-about-wifi-networks-and-wifi-adapters-using-the-wmi-and-delphi/

    But as Dorin Duminica already suggested, checking the connection to the server is better than checking the WiFi status. Of course you can combine both for detecting potential WiFi signal loss before the connection to the server will stop and the development of the signal quality when the WiFi connection comes back until it reaches a reliable level for further communication with the server.

    ReplyDelete
  3. Lars FosdalDecember 17, 2012 at 8:12 AM

    The idea is to try to minimize the recovery time when the truck is back in range.  Working offline on what normally is live data is tricky, but I've already written the failed db operations to local disk, so that they can be recovered if the app should happen to go belly up while it was offline.  If I can tweak the recovery with f.x. looking at signal strength and defer the recovery until it looks stable - I reduce the risk for partial commits.

    I've been looking at doing a heartbeat thread as well, but that's really only good for detecting connection lost, and not so good for quickly discovering a reconnect - unless I can tweak the timeout period for db operations?

    ReplyDelete
  4. Ondrej KelleDecember 17, 2012 at 9:03 AM

    On Windows Vista and higher, you could use Network List Manager API: http://msdn.microsoft.com/en-us/library/windows/desktop/aa370803(v=vs.85).aspx (you only need to import the type library to get started).

    ReplyDelete
  5. Ilya SDecember 17, 2012 at 11:51 AM

    Sounds like an example of using OpenFlow protocol (Open vSwitch) to seamlessly roam all participating wi-fi access points.

    ReplyDelete
  6. Lars FosdalDecember 17, 2012 at 12:00 PM

    I'm not sure how many access points there are in this one particular warehouse (except too few) - but it is an underground facility in an old mine, and the storage temperature is -36C, and the calculated cost per new access point was staggering.  It was cheaper to ask a code monkey to do his tricks.

    ReplyDelete
  7. Jack JohnsonDecember 17, 2012 at 2:48 PM

    I'm probably missing something, but can you just try to ping the server? I haven't looked at the Indy ping, but the commandline ping lets you set the ping count & timeout...

    ReplyDelete
  8. Lars FosdalDecember 17, 2012 at 2:51 PM

    I haven't actually considered ping.  Some of the industrial networks won't let it through by default, but I guess we could open for inside-out ping.

    ReplyDelete
  9. Warren PostmaDecember 17, 2012 at 7:28 PM

    I would use a UDP packet connecting to an endpoint service you wrote yourself. When it's down, Wifi is down.  The problem is that the signal bars and even Windows own connection status are not any guarantee that the link is up. UDP won't retry.  So give it X milliseconds, and you either get data or you don't. Done.

    ReplyDelete
  10. Lars FosdalDecember 18, 2012 at 1:07 AM

    "I could tell you an UDP joke, but there's a chance you don't get it..." ;)
    I do have a endpoint service running already.

    ReplyDelete

Post a Comment