FreeTDS Development Group

["Jackson, Craig (Gale)" <Craig.Jackson AT cengage.com>]

The idle timeout in our firewalls can be configured, but the value
is global for all firewalls in a single management domain.
(That's about a dozen redundant pairs of firewalls in our environment.)

Configuring keepalives is the path of least resistance.  It's easier
than convincing all the necessary powers to change such broad
configuration parameter.

Craig

-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org 
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of Peter Deacon
Sent: Monday, August 11, 2008 4:22 PM
To: FreeTDS Development Group
Subject: Re: [freetds] [PATCH] Configurable TCP KeepAlives

On Mon, 11 Aug 2008, Jackson, Craig (Gale) wrote:

> Your reasoning is fine from a design standpoint.
> Unfortunately, broken firewalls are a fact.

My 2cents FWIW.  I agree with both sides but for slightly different
reasons than supporting broken firewalls.

IMHO the argument that firewalls are broken is not true and largly due to
poor default configurations or lack of memory.

I challenge doubters to name a single major firewall vendor today that
does not allow configuration of maximum TCP session timeout.  You might
have to do some digging to find the setting..but the settings are most
certainly there and avaliable to be customized.


Applications that use TCP rightfully strive to treat the IP stack as a
generic stream -- when designing a wire protocol that will use TCP there
is unfortunately a little bit of overlap between layers necessary to
ensure sane behavior.

When a TCP session is active there may be no communication *at all* on the
wire and therefore neither side can know if the other has 'vanished'
without first sending data over the wire to detect an error situation.

Typically with strictly client -> server communication there is not a lot
that needs to be done when the connection is idle.  This is because if
there is a problem it will be detected and a new connection attempted upon
the next client request.

However in situations where the client sends a query to the server and
waits for a response there are three possible conditions:

1. The server is working on the query and will send the answer as soon as
its finished.

2. The server disappeared after the query was submitted and the client
will never see a response.

3. The server is still alive but one of its disk drives cought on fire and
its not able to coherently respond to the queries its currently
processing.

There is active messaging built into TCP/IP to make #2 rare and hopefully
best practices in server implementations make #3 very rare but rare !=
impossible - covering cases 2 and 3 leads to a more robust system.

When you may not know how long you should or can afford to wait for a
response...an implementation that wants better coverage and faster
recovery of possible failures will send its own keep-alives at the
*application level* to both make up for lack of transport specific
keep-alives and ensure the server is in good health. (#2 and #3)

I'm guessing (out of ignorance) that in freetds #2 might be done just by
sending zero byte messages periodically in the timeout routines to at
least cover the transport when results are pending.  0 byte sends should
not effect the protocol stream but will ususally cause data to be
transmitted over the wire invoking failure detection.  If there is a TDS
NOOP message that can be sent instead of the zero byte messages it might
get you #2 and #3.

take care,
Peter
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds