Bonjour LAex,
LOL a bit...
You are right...
Finally I ended with something close to your proposal:
function InternetConnected
local tAddress,tResult
-----
put line 1 of hostNameToAddress(the uTestUrl of stack "VTCommon")
into tAddress
if tAddress = empty then return false
set hideconsolewindows to true
put shell(quote & "ping -n 1 -w 1000" && tAddress & quote) into
tResult
set hideconsolewindows to false
return the number of lines of tResult > 10
end InternetConnected
It's for Windows, of course.
As it sets a timeout, it seems not too bad even if it is not the best...
In addition, it takes into account buffering you were talking about
and, yes, it can be a problem.
Le 21 juin 08 à 01:36, Alex Tweedly a écrit :
Eric Chatonet wrote:
Bernard,
Of course I can't send a GET request (or a LOAD): the software (I
cross my fingers :-) will be used by hundred thousands of persons
(I hope more :-)...
I'm not at all convinced that would be a problem. Every copy of
Vista has the browser set to use the same default home page
(probably msn.com); every download of Firefox is set to use the
same home page - so there are millions of users doing a get on one
of 3 or 4 highly popular pages every time they start their browser.
"hundreds of thousands" of your users checking once per time they
run your app is insignificant.
Once you ship more copies than Firefox you can start to worry :-)
However, there is a more serious problem than that ....
anything (HostNametoAddress, or openSocket, or ..) that uses a host
name will try to do a DNS lookup on the host. So you are almost
guaranteed that when the Internet connection is down, there can be
a variable, but multi-second long, delay. Even worse, there is a
distinct possibility that you will get a "false positive" result
from HostNametoAddress due to DNS caching - any responsible host/
domain will give a reasonably long DNS cache period, so if anyone
on your local network has recently connected to the chosen host,
its IP address will be cached on the Netgear (or equivalent), and
therefore it can respond with an IP address without using, or
checking, the Internet connection.
I'll try what I can get from a simple openSocket but I guess that
HostNametoAddress built-in function uses it.
That's the problem...
I'd suggest storing some numeric IP addresses, and doing something
like
shell("ping " & tIPAddr)
and checking the output for success. You could equally do a get or
load on the numeric IP Address.
You could periodically (even every time the app is run - but not in
a user-visible delay path) do a shell ("nslookup" && tHostName) to
refresh your list of IP addresss.
Le 20 juin 08 à 18:07, Bernard Devlin a écrit :
Maybe the most reliable time-critical way to check would be to
open your own
socket on port 80 to something like www.google.com. By setting the
SocketTimeoutInterval to a low value you would find out quickly
if the
timeout occured without a response. I'm thinking that you would
not even
send a GET request, just see if the socket could be opened.
bernard
On Fri, Jun 20, 2008 at 4:52 PM, Eric Chatonet <
[EMAIL PROTECTED]> wrote:
Thanks for testing at your place: it's invaluable :-)
Tests I made were with the router connected but the ADSL modem
disconnected
and I'm afraid it is the delay reason.
Le 20 juin 08 à 17:45, Bernard Devlin a écrit :
I done some further tests, and mostly I'm getting a result with
the router
disconnected of less than 30ms now. I can't reproduce the case
where I
got
14 seconds. I had a look at socketTimeoutInterval and it
seemed to make
no
difference at all. Still, if you are getting lengthy delays
then it looks
like this is not an adequate way to get a speedy test to see if
the
internet
connection is still alive.
Bernard
On Fri, Jun 20, 2008 at 3:53 PM, Eric Chatonet <
[EMAIL PROTECTED]> wrote:
Your allusion about SocketTimeoutInterval seems to be very
well thought
:-)
The problem is that I (the user) can't accept more than a 200
ms hang and
this could be not enough when he is regularly connected.
So this fails to address the problem :-(
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
