checking for Internet connection/testing "upstream" viability

[Sannyasin Sivakatirswami]

We  sure could also use some definitive answer to this also.   I am 
currently using what, by trial  and error, seems to be the least 
"blocking",  DNS  test

on testNetConnection
   if HostNameToAddress("www.gurudeva.dynip.com") is not empty then
     hilite  button "Connected" of stack "Transcription Processor"
   else
     unhilite button "Connected" of stack "Transcription Processor"
   end if
end testNetConnection


What would be really useful would be a list of all 'blocking" and 
"non-blocking" tests for a connection.

Presumably this could be/is already (??)  precisely the current 
blocking and non blocking calls of the latest libURL? i.e. if one uses 
"load URL" and tests for results you won't tie up the machine, but if 
you use "get URL' and there is no net connection, you will tie up the 
machine?? (not tested)

  HostNameToAddress doesn't seem to tie up my machine (Titanium, OSX, 
jaguar) at all if I disconnect from the net (unplug ethernet cable to 
the LAN)  and  issue a testNetConnection to test. Feedback is 
instantaneous. I dismiss the dialog and go back to typing, not even a 
burp lag.
Hopefully this emulates the modem/phone configuration of a low band 
width user.

On a related but slightly OT issue, testing for upstream connectivity: 
"how far can you see on the net" vs "are you connected" is equally 
important.  Sometimes I can get sites in Russia and sometimes not and 
it seems to be DNS problems, so I am presuming the reverse could be 
true for someone in another country trying to get through to our US 
server (s).

So, I was using "www.yahoo.com" but switched to a more obscure domain 
name that (hopefully) forces the DNS to get resolution further 
upstream, from a California server, instead of an India server (which 
most certainly will have yahoo.com but not necessarily the IP for our 
server in San Diego) in this case the editor using the app is in 
Chennai (Madras, India) .

  I really am just guessing about how DNS really  works, But. I didn't 
want the user to get DNS for yahoo.com from their India ISP and then 
have libURL turn around and  fail to open a socket to the US.  So, 
since failure for DNS  didn't tie up the machine, giving instant 
feedback, I put in the distant domain thereby averting the user going 
too far and getting frustrated with subsequent failures even though 
they were connected.

I realize that getting DNS certainly isn't proof that the server is 
"up" at all, but at least we are part way there....Though, I am told,  
I could be constructing a ghost, and this is all mute, since DNS is 
globally distributed and  ( young cybernauts tell me) *any* server 
doing DNS should have ALL domain names and their IP's for the whole 
universe, every 72 hours -- sounds impossible

An (obviously) even more solid check, if server is fixed, would be to 
download a semaphore file "yes.txt"  and, if successful, carry on...

Any smooth, rock solid, perfectly clear improvements in this area will 
be very welcome.

Sivakatirswami
Himalayan Academy Publications



On Sunday, September 29, 2002, at 06:04  AM, 
metacard-request at lists.runrev.com wrote:

> However, I'm not sure if it will let you distinguish between a
> timeout as a result of a server error or a lack of an internet
> connection.
>
> Cheers
> Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 5682 bytes
Desc: not available
Url : http://lists.runrev.com/pipermail/metacard/attachments/20020930/8bf0de42/attachment.bin