Skip to Content.
Sympa Menu

freetds - Re: [freetds] [PATCH] Configurable TCP KeepAlives

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Peter Deacon <peterd AT iea-software.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] [PATCH] Configurable TCP KeepAlives
  • Date: Mon, 11 Aug 2008 13:21:49 -0700 (Pacific Daylight Time)

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




Archive powered by MHonArc 2.6.24.

Top of Page