FreeTDS Development Group

[christos AT zoulas.com (Christos Zoulas)]

On Aug 11,  2:13pm, jklowden AT freetds.org ("James K. Lowden") wrote:
-- Subject: Re: [freetds] [PATCH] Configurable TCP KeepAlives

| 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.  
| 

>From a purist's point of view you are absolutely right; FreeTDS
should not be sending keepalives itself. In real life environments,
sometimes you are forced to run your applications in environments
that are beyond your control and idle connections are being dropped.
Unfortunately in that scenario even tcp keepalives
(http://tools.ietf.org/html/rfc1122#page-101) are not good enough
(since in the majority of the endpoints -- read operating systems
-- the timers are not configurable). To provide stable connections,
most modern protocols provide for a do-nothing packet that can be
used by the server or the client to implement tunable keepalives
(for example ssh's ServerAliveInterval).

I think it would be nice for the FreeTDS library (if there is a
do-nothing command in the TDS protocol) to implement a tunable
keepalive so that people with broken environments can have stable
connections. Right now at work we are using some firewalls that
always do packet inspection, thus keeping state, and have configurable
timeouts per port. Unfortunately setting the timeout to never makes
them run out of memory eventually :-(

christos