lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lynx-dev] altering connect time-out value


From: purslow
Subject: Re: [Lynx-dev] altering connect time-out value
Date: Fri, 30 Jul 2004 16:20:18 -0400
User-agent: Mutt/1.5.6i

040730 Thomas Dickey wrote
> On Thu, 29 Jul 2004 address@hidden wrote:
>> when it can't connect to a link, Lynx 2.8.6dev.4 times out after  23 sec .
>> in  lynx.cfg , there is a section :
>>   .h2 CONNECT_TIMEOUT
>>   # Specifies (in seconds) connect timeout. Default value is rather huge.
>>   #CONNECT_TIMEOUT:18000
>>   CONNECT_TIMEOUT:300
>> the final line is my experiment, which makes no difference to behaviour,
>> even after a reboot.  how can i make Lynx wait longer when trying a link ?
>> i'ld like something like  5 min  (you can use 'z' to disconnect).
> I'm not sure.  In HTTCP.c, there's this
> (which is the implementation of connect_timeout):
> 
>             while (ret <= 0) {
>                 fd_set writefds;
> 
>                 /*
>                  * Protect against an infinite loop.
>                  */
>                 if ((tries++ / 10) >= connect_timeout) {
>                     HTAlert(gettext("Connection failed (too many retries)."));
> #ifdef INET6
>                     FREE(line);
>                     if (res0)
>                         freeaddrinfo(res0);
> #endif /* INET6 */
>                     return HT_NO_DATA;
>                 }
> #ifdef _WINDOWS_NSL
>                 select_timeout.tv_sec = connect_timeout;
>                 select_timeout.tv_usec = 0;
> #else
>                 select_timeout.tv_sec = 0;
>                 select_timeout.tv_usec = 100000;
> #endif /* _WINDOWS_NSL */
>                 FD_ZERO(&writefds);
>                 FD_SET((unsigned) *s, &writefds);
> #ifdef SOCKS
> 
> What that says is that there are two cases:
>       a) if lynx is compiled for windows (win32) it uses the
>          connect_timeout value as documented.
>       b) otherwise, it uses a timeout of 100 milliseconds (0.1 seconds),
> and in either case, it loops, retrying a maximum of 10 times the value of
> connect_timeout (which would cancel the effect of 0.1 seconds).
> There are several places where the loop can be exited other than that -
> but they're not logged.

so Lynx does what is advertised in  lynx.cfg  when running on M$ Windows,
but does something else eg on Linux ?  or do i not understand the code ?

> I added a trace to show the counter, and timed it
> with connect_timeout set to 300 on my machine.
> It ran 3 minutes 11 seconds.

you don't say which OS you are using ...

> The log shows the error that stopped the loop:
> 
> tries 1887/3000
> tries 1888/3000
> tries 1889/3000
> TCP: Error 110 in `SOCKET_ERRNO' after call to confirm-ready connect() failed.
>         Connection timed out
> HTTP: Unable to connect to remote host for `http://ffoo.com/' (errno = 9).
> 
> Alert!: Unable to connect to remote host.
> 
> HTAccess:  status=-29999
> HTAccess: `http://ffoo.com/' has been accessed, No data loaded.
> stop_curses: done.
> 
> Acc to errno's list, a 110 is "Connection timed out", as the log shows.
> That's probably settable outside lynx, but I'm not sure where to look...

i could try something similar on my box, but you'ld have to advise me.

> This thread is related (would have been nice if it were complete):
> http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/LinuxNetdev/1998-09/0036.html
> This gives a little more insight (looking for tcp_syn_retries):
> http://www.ussg.iu.edu/hypermail/linux/kernel/0106.1/0660.html
> On my machine, tcp_syn_retries is set to 5.  I suspect yours is less.

i looked at both threads, but they seem to involve non-Lynx issues
& are both rather out-of-date anyway.

have i perhaps stumbled on a cobwebbed corner of Lynx code,
which in fact needs some updating to perform acc to specs ?

this is moderately important to me at present,
as i'm regularly encountering long delays getting DNS results
-- mb my ISP, mb local conditions, mb who knows --
& Lynx is timing out much too quickly (a/a eg Konqueror).

thanx as usual for your prompt & intelligent response (smile).

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : address@hidden
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto




reply via email to

[Prev in Thread] Current Thread [Next in Thread]