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
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
