FreeTDS Development Group

[Bob Kline <bkline AT rksystems.com>]

On Fri, 23 Jun 2000, Jon Pounder wrote:

> At 08:33 AM 6/23/00 -0400, you wrote:
> >
> >It looks like the way the timeouts work is that if tds->timeout
> >is set, then any call to read or write to the network (all calls
> >to tds_read_packet() or tds_write_packet()) will return if 
> >tds->timeout seconds has expired without reading an entire packet.
> >
> >The problem is that if the timeout period is reached while in
> >the middle of reading a packet--which is unlikely but possible,
> >the packet stream is then effectively corrupted.  The next call
> >to tds_net_read() will read the first 8 bytes off the network
> >thinking that it is a packet header when it is really the
> >last half of the last packet.
> >
> >So, in either case, timeouts are likely to break things.
> >
> >Also, if the timeout period is reached and no bytes have been
> >read yet, all calls to tds_get_<datatype> will return 0, which
> >will screw up the parsing of the TDS stream.
> >
> >So, my question: what are timeouts _supposed_ to do? I suspect
> >that they are intended to cancel the current operation, but I 
> >am not sure.
>
> Hi,
> 
> I have not been able to reach Jeff myself in a while, so I'll answer.
> 
> Yes in general, when any sort of timeout occurs the odbc layer would
> return an error, so other than getting more error details from the
> odbc layer, the application would presumably close the socket
> connection shortly thereafter without attempting any more reads. So
> as far as I see it the timeout occuring mid packet would corrupt the
> stream, but likely it occurred in the first place since there was a
> network problem already (assuming timeouts are set to realistic
> values). Then when the application closes the connection no further
> reads on the corrupted stream would occur after that.
> 
> Does this make sense ?

I think you want to be careful to distinguish between timeouts and
failures.  Not all timeouts occur because the database or the connection
to it are hosed.

Timeout handling should start with the assumption that things are ok,
except that processing of the current query is taking longer than the
application was willing to wait.  The TDS driver should send the
database a timeout token, and clear out the incoming packets to the
point where things are back in sync, and the next query will get the
response packets which belong to it.  Only in the case where you
determine that the server (or the connection) has gone to lunch is it
acceptable to leave packets in the stream that would choke the next
query.

-- 
Bob Kline
mailto:bkline AT rksystems.com
http://www.rksystems.com