FreeTDS Development Group

["Pickett, David" <David.Pickett AT phlx.com>]

When not left off or subverted by network tricks, keepalive is the TCP level
'heartbeat'.  Each side sends packets to reset TCP timers on the other side,
and should get a response that resets local TCP timers, so either side can
set the pace.  Usually, the system default is 'no keepalive', but the client
or server developer can turn it on, in a response to their defaults and
configuration, with a call like setsockopt() option SO_KEEPALIVE:
 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/win
sock/setsockopt_2.asp
The system defaults the time, 2 hours for XP:
 http://support.microsoft.com/default.aspx?scid=kb;en-us;314053
although hardening advice says 5 minutes is better:
 http://support.microsoft.com/default.aspx?scid=kb;en-us;324270
and in UNIX it is compiled in through netinet/tcp.h file: TCP_KEEPIDLE and
adjusted through commands like 'no'.

However, for API purposes, if nobody watches the fd (with poll() or select()
events or a blocked I/O operation on a dedicated thread), then it is moot.

-----Original Message-----
From: James K. Lowden [mailto:jklowden AT freetds.org]
Sent: Saturday, November 26, 2005 11:23 AM
To: FreeTDS Development Group
Subject: Re: [freetds] Connection life


martin A. wrote:
> Hello, I have a question about connection and disconnection. How can I 
> detect if a network connection is dead using db-lib? I have seen that
> there  is a function called  dbdead, but this function does not check 
> if the  network socket is alive ( I use  MS Sql Server), it never
> connects to the  server... 

The DBDEAD() function simply checks the status of the connection as
maintained by lower levels.  When the connection is dead, the library
marks it so.  As in so many things, it's easy to know if something's dead;
it's much harder to know if it will be dead soon.  

TCP has no heartbeat mechanism that I know of; TDS definitely doesn't. 
For that reason, idle connections are strictly idle: no packets are
exchanged.  If the remote end dies unexpectedly -- say, the machine loses
power -- the remote OS has no opportunity to tear down the connection, and
the local OS never receives a packet indicating the connection should be
closed.  The local status will remain "open" until a write fails or a read
times out.  

> I need this because I have a connection pooling and I havte to 
> detect connections dead to reconnect if it is needed, I keep the
> connection  without calling a dbclose for a long time. But if the dbdead
> does not check  the socket the result of calling dbdead is not reliable.
> How can I solve this problem?

The correct solution IMHO is not available to you yet.  It is described by
the db-lib docs, but not correctly implemented in FreeTDS.  

What you should be able to do is set a short timeout, say 5 seconds, and
an error handler that understands what's happening.  You issue your query.
 For easy queries, the server responds quickly, no problem.  For longer
ones, the error handler knows to wait, and tells the library to retry. 
When the error handler loses patience, it can tell the library to cancel
the operation, returning an error to the caller of dbnextrow() or
whatever.  

AFAIK that's been the standard answer for 20 years.  We're almost there.  

Regards, 

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