Tcl - Check if a connection to the internet exists

Author

Check if a connection to the internet exists

Helmut Giese

2006-08-21, 8:01 am

Hello out there,
before starting a possibly lengthy upload operation I would like to
know if the machine is connected to the internet at all. What would be
a simple way to achieve this?
Thanks and best regards
Helmut Giese

Michael Schlenker

2006-08-21, 8:01 am

Helmut Giese wrote:
> Hello out there,
> before starting a possibly lengthy upload operation I would like to
> know if the machine is connected to the internet at all. What would be
> a simple way to achieve this?

Depends.

Some people simply use http::geturl -validate www.google.com and asume
that google is always there.

If you have control over the reveiving machine, install an echo service
you can connect to, to check if it is up and reachable.

If you want to avoid blocking name service lookup (DNS) calls, you have
to check in different ways (on windows for example with TWAPI by using
the appropriate apis).

Michael

davidhbigelow@simplifiedlogic.com

2006-08-21, 8:01 am

> Some people simply use http::geturl -validate www.google.com and asume
> that google is always there.

What about networks that require a proxy?

Dave

Michael Schlenker

2006-08-21, 7:02 pm

davidhbigelow@simplifiedlogic.com schrieb:
>
>
> What about networks that require a proxy?

Then this simplistic approach fails.

You could tinker around with the tcllib autoproxy package and or other
options, but a simple 'am i connected' check will fail with most
proxies. (which is basically what most non-transparent proxies are
about : limiting access)

For heavily secured sites you need better checks, but it often boils
down to either:

1. You have internet connectivity
2. You have no internet connectivity

If 2. happens due to a restrictive proxy or a missing cable only affects
how you can fix it, automatically with something like autoproxy or by
asking the user.

But in both cases the only meaningful check would be a connection to the
real target server _and_ target service, using some kind of echo message
or status call. Otherwise there may be all kinds of problems even if you
can connect to the internet in general. Routing problems, missing DNS
entries, expired SSL certificates, service crashed on the target server
and so on.

Michael

Helmut Giese

2006-08-21, 7:02 pm

On Mon, 21 Aug 2006 13:13:04 +0200, Michael Schlenker
<schlenk@uni-oldenburg.de> wrote:

>Helmut Giese wrote:

Hi Michael,[color=darkred]
>If you want to avoid blocking name service lookup (DNS) calls, you have
>to check in different ways (on windows for example with TWAPI by using
>the appropriate apis).
you're way ahead of me. I hadn't thought of it but I think I would
like to "avoid blocking name service lookup". Could you please
elaborate a bit on "the appropriate apis"?
Thanks and best regards
Helmut Giese

Ralf Fassel

2006-08-21, 7:02 pm

* hgiese@ratiosoft.com (Helmut Giese)
| before starting a possibly lengthy upload operation I would like to
| know if the machine is connected to the internet at all. What would
| be a simple way to achieve this?

Simply try to connect to the upload server. If the connections
succeeds, you're connected :-) Note that you can use the -asynch
option of 'socket' to avoid blocking in the initial connection
attempt.

R'

Darren New

2006-08-21, 7:02 pm

Ralf Fassel wrote:

> * hgiese@ratiosoft.com (Helmut Giese)
> | before starting a possibly lengthy upload operation I would like to
> | know if the machine is connected to the internet at all. What would
> | be a simple way to achieve this?
>
> Simply try to connect to the upload server. If the connections
> succeeds, you're connected :-)

Actually, there are two ways to interpret your question:

1) Is the machine capable of accessing the server I want to connect to?

2) Is the dial-up connection established and ready to go?

These are two different questions. The first is obviously pretty easy to
figure out, and obviates the need for (2) as it will dial the phone if
you just try it.

The second may not give you any useful information in terms of "do I
prompt for a bunch of information when I can't upload anyway", unless
you're trying to only start the transfer "in the background" when the
user is already connected. If you *are* trying to upload in the
background, and you're using Windows, I suggest you look into using the
BITS service (background intelligent transfer service) to do your uploads.

--
Darren New / San Diego, CA, USA (PST)
This octopus isn't tasty. Too many
tentacles, not enough chops.

Michael Schlenker

2006-08-21, 7:02 pm

Helmut Giese schrieb:
> On Mon, 21 Aug 2006 13:13:04 +0200, Michael Schlenker
> <schlenk@uni-oldenburg.de> wrote:
>
>
> Hi Michael,
> you're way ahead of me. I hadn't thought of it but I think I would
> like to "avoid blocking name service lookup". Could you please
> elaborate a bit on "the appropriate apis"?

Take a look at the options under:
http://twapi.sourceforge.net/network.html

Michael

Helmut Giese

2006-08-22, 7:02 pm

On Mon, 21 Aug 2006 11:18:09 GMT, hgiese@ratiosoft.com (Helmut Giese)
wrote:

>Hello out there,
>before starting a possibly lengthy upload operation I would like to
>know if the machine is connected to the internet at all. What would be
>a simple way to achieve this?
>Thanks and best regards
>Helmut Giese

Thanks to all of you and sorry for the delay.
I'll tug away all your suggestions, but for the time being the feature
simply got dropped.

What I figured to be a simple question turned out to have lots of
different aspects - and this in a domain where I get lost easily.
Dial up connection: I don't even have one for testing - but I think I
can setup a notebook to try it out.
Blocking name service lookup: I would never have thought of it, but in
all probability it would have bitten me.
Proxies: Just leave me alone, please.

Anyway, this upload feature has begun a life of its own. It started
out with a simple idea: In case of error transfer all relevant
information to me without bothering the user too much (of course I ask
his permission and he has the opportunity to add comments).
When an upload failed I just told the user 'Sorry, an error occurred,
but thanks for trying." and deleted the info in question. Why not.

Useful & tiny & trivial extension: Some users might be willing to
report glitches or inconsistencies in the program (something they
_see_ but which the program cannot detect itself), and the machinery
was already in place, so let's just add another menu entry and the
user can report all he wants.

Oh, had I known ...

Some time later I realized that now a reaction like "Sorry, but thanks
for trying" in case of transmission failure was of course no longer
possible: A user was trying to be helpful and had invested work - so I
couldn't just drop it but had to save it.
- This could concern multiple incidents, so I couldn't get away with
handling only one set of information.
- Saving it only makes sense if there is a possibility to re-try
later. Of course we attempt to re-send only those which were
unsuccessful so far, so there is a need for some additional state
information. And no, we cannot blindly delete everything once it has
been sent - maybe the user wants to keep it?

See what I mean with "a life of its own"? From a small, simple feature
which seemd useful and was technologically challenging it has grown to
a venerable sub-system of its own, which has taken a lot more time
than I had ever intended to invest.

And than the idea of checking if a connection to the internet existed,
so that we could warn / inform the user that he might have to
establish said connection first.

No!!! Enough hand-holding, dear user. You will have to figure this out
for yourself. You will get an error message popping up at you
containing a hint that maybe the connection wasn't establöished yet -
and that's it.

-----------------------

I thought I'd share this with you - a nice litle example to be filed
away as 'Feature creep, incident #137'.
Keep up the good work - and be conservative with your features :)
Helmut Giese

Ralf Fassel

2006-08-22, 7:02 pm

* hgiese@ratiosoft.com (Helmut Giese)
| - Saving it only makes sense if there is a possibility to re-try later.

Why not simply save the information to a file and tell the user to
mail it to you later? They should be able to attach a simple file to
some email...

R'

Helmut Giese

2006-08-23, 7:03 pm

On Tue, 22 Aug 2006 19:32:26 +0200, Ralf Fassel <ralfixx@gmx.de>
wrote:

>* hgiese@ratiosoft.com (Helmut Giese)
>| - Saving it only makes sense if there is a possibility to re-try later.
>
>Why not simply save the information to a file and tell the user to
>mail it to you later? They should be able to attach a simple file to
>some email...
Hi Ralf,
I started out this way and it didn't work.

Tom Conner

2006-08-23, 7:03 pm

"Helmut Giese" <hgiese@ratiosoft.com> wrote in message
news:44ec7ca9.14793515@News.Individual.DE...
> On Tue, 22 Aug 2006 19:32:26 +0200, Ralf Fassel <ralfixx@gmx.de>
> wrote:
>
> Hi Ralf,
> I started out this way and it didn't work.

What didn't work? You couldn't save it to a file, or the user didn't email
it?

Why not just email it to yourself. If the internet connection is down it
just sits in the Outbox until the connection is up.

Donal K. Fellows

2006-08-23, 7:03 pm

Tom Conner wrote:
> What didn't work? You couldn't save it to a file, or the user didn't email
> it?
>
> Why not just email it to yourself. If the internet connection is down it
> just sits in the Outbox until the connection is up.

We've been round this loop before in previous threads. Email is awkward
to make work with attachments unless you bind yourself to specific
mailers (which is messy; you can't assume very much at all about what
users are using).

To me, based on Helmut's messages it seems that we're in the case of
"cannot figure out any way to fix things automatically". There's an
arbitrarily complex networking configuration and the machine is quite
possibly offline too. There just isn't a workaround that doesn't involve
direct user intervention. Anything else and you're playing a kind of
random guessing war with an unknown number of opponents, and those
aren't rules *I* like.

Donal (suspecting that Helmut's requirements are either unrealistic or
impossible. Or both.)

Helmut Giese

2006-08-24, 8:02 am

On Thu, 24 Aug 2006 00:05:45 GMT, "Donal K. Fellows"
<donal.k.fellows@manchester.ac.uk> wrote:

>Tom Conner wrote:
>
Hi Donal,
many thanks for this concise summary.
>We've been round this loop before in previous threads. Email is awkward
>to make work with attachments unless you bind yourself to specific
>mailers (which is messy; you can't assume very much at all about what
>users are using).
>
>To me, based on Helmut's messages it seems that we're in the case of
>"cannot figure out any way to fix things automatically". There's an
>arbitrarily complex networking configuration and the machine is quite
>possibly offline too. There just isn't a workaround that doesn't involve
>direct user intervention. Anything else and you're playing a kind of
>random guessing war with an unknown number of opponents, and those
>aren't rules *I* like.
>
>Donal (suspecting that Helmut's requirements are either unrealistic or
> impossible. Or both.)
Hm, we'll see. The feature is implemented, there are some more
features left to add and then it goes out to a big field test.
I'll be keeping my fingers crossed - though in this domain this
usually doesn't make much of a difference :(
Thanks for your help and best regards
Helmut Giese

Sponsored Links