At 08:13 PM 15/08/2004 -0700, you wrote:

>On 8/16/2004 at 11:56 AM Helen Borrie wrote:
>
> >
> > I don't observe this at all with either RedHat 8 (running 1.5.1 Classic)
> > or
> > Mandrake 9.1 (currently running 1.5.0). I don't have DHCP running on
> > either server - all IP addresses used by Firebird clients are statically
> > configured in the hosts files of servers and clients and connections
> > never
> > time out.
> >
> > Likewise, I use the same tactic to prevent DHCP on the Windows servers
> > from
> > stealing IP addresses that Firebird clients use.
> >
>
>I had just been living with this, but the conversation about it is
>providing some motivation to dig deeper, especially as you don't see the
>problem.
>
>I am not using DHCP on any of the computers involved in this setup. There
>IS, however, a NAT server/firewall between the client and the server (with
>the server on the WAN side of the firewall and the client on the trusted
>network side). I don't believe that has an effect, but I can double-check
>by installing FB 1.5 on another Linux machine I have inside the firewall,
>although it is SUSE Linux 9.1, not Fedora. I'll work on that tomorrow
>evening and report the results here.
>
> > Have a look to see what Fedora's settings are for the tcp_keepalive
> > parameters. AFAIK, they interact this way:
> > tcp_keepalive_time = s
> > tcp_keepalive_intvl = i
> > tcp_keepalive_probes = p
> > As I understand it, after 3 * (s + i) seconds of idle time at that IP
> > address, the socket will be considered dead and will be disconnected,
> > releasing the IP address back to the pool. (But check this in the man
> > files
> > and also look in the firebird log for the exact inet error code that
> > occurred).
> >
>
>Firebird log shows error code 110.

That is ETIMEDOUT, i.e. the server timed out the connection because it took
too long to respond. Cause for the timeout could be one or more of a lot
of things: faulty NICs, cables or plugs; an abnormal server shutdown; if
it's a Classic server, the number of allowed connection instances might
have exceeded the number configured for xinetd.

> Windows client shows no errors at all until after I issue the first
> request after being idle.

As expected. If the client is idle and the socket keepalive has timed out
for whatever reason, then the client won't know it's not connected until it
tries to resume a conversation through a socket that's not there any more.

/heLen