[freetds] SOLVED: timeouts

Godefroid Chapelle gotcha at bubblenet.be
Mon Jan 15 03:05:49 EST 2007


James K. Lowden wrote:
> If you've been following the list at all lately, you know Frediano and I
> have been working on timeout logic.  The history of this part of the
> project isn't particularly pretty.  Like a lot of things, it got attention
> when someone got around to it, and only enough attention to fix the
> immediate problem.  It's a hard problem, IMHO, because you have to know
> something about tcp/ip networking, something about SQL Server and TDS,
> something about the API definitions, and quite a bit about our
> implementation.  
> 
> A lot of FreeTDS can be coded simply by reading the documentation and
> writing conformant code.  A fair bit of libtds involves adhering to the
> protocol, seeing what the server sends and responding such that it doesn't
> close the connection.  There's also a chunk that prepares or parses
> packets.  The networking part is quite small: counted in lines of code,
> net.c is only 6% of libtds.  
> 
> Apart from technical knowledge, errors from network timeouts are difficult
> to handle because each client library has its own way to do it.  ODBC is
> the simplest: the application sets a timeout value and the login/query
> succeeds or fails, period.  ct-lib is the closest to the wire: the
> application can catch the error and, if it so chooses, send a cancel
> packet or tell libtds to break the connection.  db-lib has an ungainly set
> of options that make sense only if you spend a lot of time understanding
> their implications.  db-lib and ct-lib share the capability of installing
> a callback for errors that can direct the library.  
> 
> Over the years I've posted pleas from time to time for some network expert
> to swoop in and fix the timeout logic.  No one did.  Little did I know
> that networking knowledge was less than half the battle.  Now that I've
> done it, I can say it's not that hard to learn tcp/ip basics and how to
> use non-blocking sockets. The real work was to define an interface to
> libtds suitable to all the client libraries, and to make them use it.  
> 
> That work I now declare done. 

Thanks for the work done !!!

Before mailing the list, I had taken a look to check if I could help but 
I must say it was not obvious. IOW, congrats.

> Timeouts work as specified.  If you write
> your handler correctly, you can tell libtds to keep waiting as long as you
> want to, request it cancel the pending request, or tell it to give up and
> close the connection.  If you set a timeout of 20 seconds and pull out the
> wire, your db-lib handler will get SYBETIME 20 seconds later.  After that,
> it's up to you.  
> 
> As an added bonus, dbsettime() works, too.  So you can write your own
> interrupt handler if you want to.  I wonder if there's a single
> application out there waiting for that feature.  We could also have
> dbsetidle() and dbsetbusy().  Someone has to ask, though.  dbpoll() is
> possible, too, and only a little more work.  
> 
> ODBC's specification is a little vague.  Probably if you set a query
> timeout of 20 seconds and pull the wire, you'll get a failure in 40
> seconds, because when the timer expires the library will make one
> good-faith effort to cancel the pending request (which will itself timeout
> 20 seconds later). I'm sure Frediano made a sensible choice in any case.  
> 
> As it happens, my own use of FreeTDS doesn't depend on timeouts working
> correctly.  I created my own itch, if you will; I didn't like the
> perplexed messages that show up on this list every few months saying that
> timeout didn't seem to work right.  A person can waste a lot of time
> before coming to the conclusion that it's FreeTDS's fault.  Fixing the
> code was my little act of mercy.  
> 
> So, Happy New Year.  Thanks for listening, and enjoy your subtly improved
> library.  
> 
> --jkl

-- 
Godefroid Chapelle (aka __gotcha)- BubbleNet  http://bubblenet.be



More information about the FreeTDS mailing list