FreeTDS Development Group

["Scott C. Gray" <gray AT voicenet.com>]

On Fri, 23 Jun 2000, Jon Pounder wrote:

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

Yes it makes sense, however I have an, err, more appropriate proposal.

I currently have cancels working fairly acceptably and will hopefully
be rolling the changes in sometime soon.  The way I would recommend
doing this is to have the ODBC layer install a general timeout handler
(as opposed to just the longquery handler that is there right now).
Then, when this handler is called it can issue a tds_cancel(TDS_CANCEL_ATTN)
which will cancel the current query, causing whatever tds call
is currently waiting for network I/O to return TDS_CANCELED.
This will time the query out, leaving the connection in a usable
state.

I am not sure if this will deal with your networking failure scenario
as it expects the server to eventually acknowledge the cancel request.

-scott

> 
> 
> At 08:33 AM 6/23/00 -0400, you wrote:
> >
> >As mentioned before, I have been in the process of imlementing cancels
> >in the TDS layer.  As part of this effort I had to re-implement most
> >of the network calls (I actually implemented a little network layer).
> >Everything is working dandy except that I a trying to roll the
> >timeout changes back in that were made by Jeff (the comments don't say
> >Jeff's last name or e-mail address). 
> >
> >While I am doing it I discovered something that concerns me.
> >
> >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.
> >
> >-scott
> >
> >--
> >Scott C. Gray <gray AT voicenet.com>     "my keybard is brken"
> >       http://www.voicenet.com/~gray/sqsh.html

-scott

--
Scott C. Gray <gray AT voicenet.com>     "my keybard is brken"
       http://www.voicenet.com/~gray/sqsh.html