Determining if a client PC has an Internet connection

[Cliff Wells]

On Sun, 2004-09-19 at 11:46 +0200, Fredrik Lundh wrote:
> Cliff Wells wrote:
> 
> > I'm writing an application that needs to know if an Internet connection
> > is available.  Basically, I want to have something similar to what a lot
> > of email clients have, where the app can work either in "online" or
> > "offline" mode (it keeps a cache of downloaded info, so it can work
> > without a connection if needed).
> 
> on windows, you can use InternetCheckConnection:
> 
> http://msdn.microsoft.com/library/en-us/wininet/wininet/internetcheckconnection.asp
> 

I may in fact fall back on this for Windows.  However, since the app
runs on Windows, Linux and OSX, a cross-platform solution would be best.


> 
> > The basic problem is this: it downloads info (RSS feeds) from a variety
> > of sources.  Any one (or more) of these could conceivably fail to
> > download, so simply waiting for a timeout isn't sufficient (not easy to
> > differentiate between having a bad server and the client not having a
> > connection).  Further, if it waits (say 30s) for the timeout to occur,
> > this is going to be a bit annoying to the user.
> 
> another solution would be to use asynchronous sockets, and only up-
> date the local cache when you get new data from the server (set a flag
> in the user interface if the server times out; if all channels are flagged,
> the users will probably figure things out by themselves).  bits and pieces:
> 
>     http://effbot.org/zone/effnews-1.htm (asynchronous client)
>     http://effbot.org/zone/effnews-2.htm (parsing)
>     http://effbot.org/zone/effnews-3.htm (connection management)

Yours was actually the code that I started studying prior to undertaking
this project (it was a big help).  However, I'm using Twisted and a
hacked-up version of Mark Pilgrim's feedparser at this point.

The main reason I can't simply let things time out at this point is that
a requirement for the app (as silly as it might seem) is that the user
be notified that they are offline.  So there needs to be a clear-cut
definition within the app of the current state of affairs.   More
importantly, if the app is "online", timing out is returned as an error
to the user, whereas in the "offline" state, as long as the data is
cached, there is no error.  Also, in the case of being offline and there
is no data in the cache, the error message is to be different than if
the app is online and the connection fails (yes, sigh).

As I mentioned in another post, it seems a reasonable solution would be
to determine the PC's DNS search path and then try those hosts.  If they
are unreachable then assume the connection is down.  This would seem to
be reasonably cross-platform (although admittedly, exactly how this is
done would probably vary across platforms)

Regards,
Cliff

-- 
Cliff Wells <clifford.wells at comcast.net>