[Top][All Lists]

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

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

From: Thomas Dickey
Subject: Re: [Lynx-dev] altering connect time-out value
Date: Sat, 31 Jul 2004 13:18:05 -0400
User-agent: Mutt/1.5.4i

On Fri, Jul 30, 2004 at 04:20:18PM -0400, address@hidden wrote:
> 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 .
> 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 ?

As I understood your question (and bear in mind that I can be mistaken -
had to google around for a while to re/learn the bits to answer it),
the timeout was for a connect (not resolving DNS in particular).
> > 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 ...

Debian (testing).  iirc, you were using GenToo.  It occurred to me when
reading the email thread that it's not unlikely that someone tuned the
TCP settings to provide a short timeout.  Analogously, I occasionally see
people who've "fixed" ncurses by setting the timeouts to zero.  (Works
fine on the console ;-)
> > 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 `' (errno = 9).
> > 
> > Alert!: Unable to connect to remote host.
> > 
> > HTAccess:  status=-29999
> > HTAccess: `' 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.

"lynx -trace address" (whatever address you're trying to lengthen the timeout
on) should show the TCP error.  The "tries" lines were ones I added to check
that my reading of the code was right - that there wasn't some shortening
of the timeouts during the select.
> > This thread is related (would have been nice if it were complete):
> >
> > This gives a little more insight (looking for tcp_syn_retries):
> >
> > 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.

They're actually topical - they seemed to be talking about the same area.
> 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).

well - I'm not sure.  It's possible that you're getting a fast connection to
a DNS server which is taking a while to respond.  That would be a different
problem from a short timeout from a connection to a resolved address.

The file /proc/sys/net/ipv4/tcp_syn_retries is something that you can look
inside and see if your TCP settings are tuned the way I was reading.  If
I peek inside mine, it shows a "5".  A smaller number would indicate that
your timeouts are correspondingly smaller (though the email thread indicates
it is not linear).

Some (perhaps most) of the settings under /proc can be modified while the
system is running, e.g., (as root of course), this might allow you to
        echo 5 >/proc/sys/net/ipv4/tcp_syn_retries
(and some of those settings are tweaked that way while the system is starting).

Thomas E. Dickey <address@hidden>

reply via email to

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