FreeTDS Development Group

[Peter Deacon <peterd AT iea-software.com>]

On Sat, 6 Jan 2007, James K. Lowden wrote:

> On sending the cancel, we may get EAGAIN.  We then select(2) until we know
> either 1) it succeeded or 2) it didn't.  On failure, close the socket,
> tell the app, and fail the function.

> On success, we read(2) and wait for a reply with select(2).  If we get
> one, great.  If the client's timeout expires, we tell him, but all we can
> do is wait some more or give up and close the connection.  If he tells us
> to cancel again, we wait some more.

> All the while we're waiting, we have a read pending.  If the server can
> communicate with us, we might learn he's closed the connection (FIN
> arrives, read returns 0).  If the wire's broken, we might never get the
> FIN but eventually read would return <0 and errno would be ETIME.  Either
> way, we have to close the connection and mark it DEAD.

You can have a TCP connection open for a year and have absolutely no 
data go through it and it would still be concidered a valid, active 
connection.

Read does not generate any messages on the network and TCP has no concept 
of keepalives so this needs to be handled by TDS.  Offhand reads don't 
timeout unless you use select.

> So maybe the code isn't so wrong after all. 
> You concur?

If it matters and if the code is wrong is really dependant on how the 
database servers react.  In the case of cancel it might not be such a big 
deal to send a handful of cancel messages however in other areas resending 
previous commands rather than a NOOP might ruin someones day.

take care,
Peter