Socket timeout not working with libUrl

[Alex Tweedly]

Alex Tweedly wrote:

>> When you run this script and you're not connected to the internet 
>> here's what happens:
>>
>>    1) If I open the socket with an ip address, e.g. 64.125.128.80, my 
>> 5 second timer will fire, and I can close the socket and exit from 
>> the routine.
>>
>>    2) If I open the socket with a domain address, e.g. 
>> www.webphotospro.com, Mac OS X does a DNS lookup, puts up the rainbow 
>> rotating color cursor, and hangs until the DNS lookup fails.  On my 
>> machine this takes 60 seconds (apparently it's dependent on how many 
>> dns servers you have listed).
>>
>> I'm guessing this is a RunRev bug, but I can't be sure.  Basically 
>> RunRev hangs for 60 seconds while the DNS lookup takes place during 
>> the "open socket" call -- it doesn't send a socket timeout, and it 
>> doesn't the "My5SecondTimeout" message either.
>>
>> Can confirm this?
>
>
> Yes.
>
> you may have missed the email I sent earlier in this thread, re bug 
> 2117 Engine blocks on DNS query
>
> Take a look at that bug report for more details. You can check for 
> dnsservers - which will prevent the problem occurring in most cases, 
> but there are still some cases where it will fail.

Unfortunately, BZ 2117 is currently being treated as a problem with 
RevOnline, rather than dealing with the fundamental problem of there 
being no way to query DNS without the risk of blocking for 40-120 
seconds (or longer). Your experiments above prove that it is a 
fundamental problem, applying even to the "non-blocking" parts of libURL.

Since BZ 2117 has been closed once already as "can't be fixed", you may 
want to open a Bugzilla report to record the general problem, and simply 
mention 2117 as a special case of it. Even though it can't be fixed in 
the normal case (of, e.g., put URL ...) it can easily be provided as a 
non-blocking function, for use within non-blocking functions such as 
libURL, or revonline checks.

In the meantime, there is a work-around - but it's pretty ugly .....

1. write a shell script which does a ping to the machine you need to 
talk to, and saves its results to a log file.
In my case, I created a file called    C:\MYPING.BAT    which contains

> ping www.tweedly.net > c:\ping.txt

(of course, you could create this dynamically, so as to handle any 
target machine).

2. In your app, "launch" this shell script then start a timer to check 
for the existence of the log file, and then check the results

> local lStart
>
> on mouseUp
>   delete file "C:/ping.txt"
>   set hideconsolewindows to true   -- Win only
>   put the seconds into lStart
>   launch "C:/myping.bat"
>   send "tryNow" to me in 5 seconds
> end mouseUp
>  
> on tryNow
>   local tFile
>   put "trying" && (the seconds - lStart) & cr after field "lockedField"
>   if there is a file "C:/ping.txt" then
>     put URL "file:c:/ping.txt" into tFile
>     filter tFile with "*Reply*"
>     if the number of lines in tFile > 0 then
>       put "success " & word 3 of line 1 of tFile & cr after field 
> "lockedField"
>       exit "tryNow"
>     end if
>   end if
>   if (the seconds - lStart) > 80 then
>     put "failure after 80 secs" & cr after field "lockedField"
>   else
>     send "tryNow" to me in 5 seconds
>   end if
> end tryNow

3. handle the minor variants needed for each platform ....

(note - tested in my situation where I regularly encounter the problem 
you described. While I can't think of other circumstances where I would 
expect this to fail, I haven't done extensive testing of other scenarios).

Or, alternatively, .....

instead of using www.webphotospro.com, use the hard-wired IP address; 
when that fails, use another hard-wired address to check for the 
presence of an Internet connection - and only then try again using the 
hostname (and store the IP address used). This last (blocking) case will 
only happen when  your web site address has changed, and the user has an 
internet connection, but his DNS servers are either dead or unreachable 
- which is going to be very rare for any reasonable ISP. 

-- Alex.



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.6 - Release Date: 27/01/2005