FreeTDS Development Group

[Peter Deacon <peterd AT iea-software.com>]

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