Skip to Content.
Sympa Menu

freetds - Re: [freetds] new network timeout code

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Peter Deacon <peterd AT iea-software.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] new network timeout code
  • Date: Sat, 6 Jan 2007 16:22:52 -0800 (Pacific Standard Time)

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




Archive powered by MHonArc 2.6.24.

Top of Page