FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Peter Deacon wrote:
> On Sat, 6 Jan 2007, James K. Lowden wrote:
> > Code is wrong.  What if first cancel is lost in the network?  (Cf.
> > TIME_WAIT.)  On timeout waiting for a cancel acknowledgement, we must
> > send another cancel request if tdserror returns TDS_INT_TIMEOUT.  What
> > the server does with two cancels is up to the server.  Eventually
> > we'll get either an acknowledgement or EOF.
> 
> Data doesn't get lost when using TCP.  If it can't be transmitted and
> the  OS finally gives up that just effect the state of the connection
> itself.

I see your point.  tcp will either deliver the packet or time out. 
(TIME_WAIT determines how long it waits between retries.)  

> If you send cancel successfully it is received, when doing it async you 
> will be notified via select if it isn't (tcp connection) times out.

Understood, now.  Thanks. 

> If the server does not respond to your first message sending more isn't 
> going to change anything.  The only benefit to sending additional
> messages  is the realization that you will never get a response in the
> case the  remote end disappears/isn't reachable/has long since forgotten
> about you.  To cover those situations you normally send NOOP messages
> assuming the TDS  protocol has them otherwise maybe the extra cancel
> messages are the NOOPs  and I should just go away :)

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.  

So maybe the code isn't so wrong after all.  

You concur?  

Regards, 

--jkl