FreeTDS Development Group

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

Your reasoning is fine from a design standpoint.

Unfortunately, broken firewalls are a fact.

It would have been a feature to make this configurable in freetds.  However,
Since it's nearly always configurable system-wide by messing with the TCP
parameters, it's not really necessary.

Modifying the application code to configure the keepalives is an option
that may not be available to the sysadmin or DBA trying to work through
this problem.

Craig

-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org 
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of James K. Lowden
Sent: Monday, August 11, 2008 2:14 PM
To: FreeTDS Development Group
Subject: Re: [freetds] [PATCH] Configurable TCP KeepAlives

Jackson, Craig (Gale) wrote:
>
> Due to the increasing use of things like firewalls, we're finding many
> situations where the traditional 2-hour keepalive for TCP is useless.
> (Our firewalls have a 60-minute idle timeout that is not easily
> configurable.)

Your reasoning is: "My firewall emulates broken routers by dropping
perfectly good connections.  Therefore, FreeTDS should be configurable."

Should we be able to set DNS timeouts, too?  Ethernet link options?

Please allow me to explain my thinking more fully.  I don't frequently
turn down patches.

The behavior controlled by these parameters has nothing to do with the
Tabular Data Stream.  TDS has a connection timeout, a login timeout, and a
query timeout.  Those all control how long a client is prepared to wait
for a response from the server, over whatever kind of link is in use.
There is nothing in them specific to TCP/IP.

FreeTDS configuration parameters affect the Tabular Data Stream only, not
the application, and not the underlying communication layer.  Non-TDS
behavior is best controlled by non-TDS tools.

Database programmers and administrators are in general unschooled in
TCP/IP theory.  They are ill-equipped to compensate for broken network
configurations.  When perfectly good network connections fail without any
attributable cause in the client or server, they had best consult the
network folks who (one hopes) do have the skills and tools to diagnose and
explain them.  The organization can then decide whether to restore the
transmission control protocol (cf. RFC 1122) or, as yours apparently has,
to place the burden of coping with unreliable networks on the application
programmer.

Again, I have no problem exposing the underlying endpoint for manipulation
by ioctl(2).  But, because the keepalive parameters are invisible to TDS
per se, they should not be configured by the library.

Regards,

--jkl
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds