[freetds] new network timeout code
Peter Deacon
peterd at iea-software.com
Sat Jan 6 19:22:52 EST 2007
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
More information about the FreeTDS
mailing list