Re: [Firebird-devel] More network problems

[Brad P. <br...@li...>]

On Friday 11 May 2001 01:07, you wrote:
> Brad Pepers wrote:
> > Any ideas on where to go from here?  This should be easy to duplicate
> > again. Just use isql on a localhost:filename.gds type connection and
> > leave it running for 40 minutes.  If you do a "netstat --ip -o" after the
> > hour, you will likely find that the Recv-Q of the client is 124 and the
> > Send-Q of the server is now going up and there is a timeout on the
> > server.  Once the server hits 15 retries (around 64 bytes in the Send-Q),
> > it gets a ETIMEDOUT return and exits with an error message in
> > interbase.log that it got an error #110. If you then type in a command
> > from isql, it will fail since the connection to the server is done.  If
> > someone else could verify this happens on their system, it would be nice!
> >  You have to have the other select bug fixed first though or you will
> > never make it past 1 minute of leaving isql running...
>
> I will try it.

Thanks!  What Linux version are you running?

> BTW I use my scripts:
>
> get_tcp_timeout:
> cat /proc/sys/net/ipv4/tcp_retries2
>
> and
>
> set_tcp_timeout:
> echo $1 > /proc/sys/net/ipv4/tcp_retries2
>
> to control tcp_timeout

Ok but what does tcp_retries2 really control?  And under what conditions is 
it used?

> There is some more of this in /proc/sys/net/ipv4

Yes I've looked at all of them and read the limited docs on it from the 
/usr/src/linux/Documentation/network/ip-sysctl.txt file but don't really grok 
yet which timers do what under what circumstances.  I've got the Stevens 
TCP/IP Illustrated Volume 1 (The Protocols) and also Unix Network Programming 
and so far I've not seen anything that I can relate to these retries.  The 
best match I can find is Chapter 21 of TCP/IP Illustrated which is on TCP 
Timeout and Retransmittion.  It looks to me like the loopback "lo" device 
stops sending ACK's back to the server.  This triggers the normal TCP timeout 
and retransmit algorithm involving exponential backoff

So to me the whole trick is why the loopback device stops acking itself!  I'm 
running tcpdump on it right now to watch what happens at the 124 byte point.

-- 
Brad Pepers
br...@li...