FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Jackson, Craig (Gale) wrote:
> FYI, the default timeouts in Berkeley-derived code are much greater than
> a minute.  As I recall, there was a doubling backoff until it got to 64
> seconds, and then it tried 8 times at 64 seconds.  It came to 10 minutes
> or so.

Acknowledged.  I spent a little time tonight with Stevens's "UNIX Network
Programming".  It says roughly the same thing.  

It's also worth mentioning that write(2) won't necessarily fail in the
face of a peer host crash.  It returns when the userspace buffer is copied
to the kernel buffer.  If the peer disappears before the data are
delivered, that won't become clear until the next operation fails.  

In db-lib terms, that means that depending on the size of the query,
dbsqlsend() might block 10 minutes or more for network reasons, or might
return SUCCEED without the query actually ever being delivered.  The next
function call would be to dbsqlok(), which would fail because the server
didn't respond to the query:  Either the query timeout expires, or the
underlying select(2) would return an error.  

Regarding keepalives, Stevens points out that it might better be called
"make-dead".  Even with the standard 2-hour interval, a well timed
15-minute network outage can make a good idle link appear dead.  All it
need do is coincide with the 10 or so minutes the keepalive logic will use
to retry the keepalive packet. 

Of course in your case the keepalive's purpose is almost the opposite of
its original intention: rather than confirming the peer is still up in
case of a network failure, it's *preventing* a network failure by
confirming the peer is still up. 

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

I understand and I sympathize.  You're working around your own management,
never fun.  I'm sure you're not alone.  

>From your description, it's a disaster.  Not only is the firewall
needlessly wrecking good links, it apparently is doing so without a proper
teardown, without sending FIN packets to signal the TCPs that the link has
been broken.  Ghastly.  

Reminds me of the days when Earthlink was my ISP, and would drop idle PPP
connections after 10 minutes or so.  I'd be reading some README trying to
figure out how to install something, and poof my modem lights would go
dark.  I had to violate the TOS and ping them once every minute just to
stay off hook.  They never complained and I never explained.  

--jkl