Subject: time-outs (was Re: c-ares Digest, Vol 20, Issue 4)

time-outs (was Re: c-ares Digest, Vol 20, Issue 4)

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Wed, 15 Aug 2007 15:48:26 +0200 (CEST)

On Mon, 13 Aug 2007, Anlin Zhang wrote:

Please don't top-post, please keep a sensible subject and if you are going to
post to the list, please consider not using the digest mode of delivery...

> The solution I have posted at this stage was not intended to be mature
> enough to merge into the main line (not a patch yet). I was just "asking for
> questions" like "do you have better solution?" since I'm not quite
> understanding the main code line yet. You may treat it as an example of
> solution (at least it satisfied our need for high availability).

I'm still not happy with using keep-alive as a means to just discover a
time-out. Why can't we/you just use non-blocking sockets and use the normal
time-out mechanism?

> I may spend more time later on c-ares and wish I can contribute to it in a
> way that it requires.

Great!

As you may know, I spend lots of time in a number of open source projects and
c-ares is not always on the top of my agenda... And I do have a family and a
paid job to take care of too.

> BTW, the keep alive option (and keepcnt, keepintvl) only applies to the
> specific tcp connection, won't affect other sockets in local linux host or
> remote host.

Of course not, but if the connection is used by an application for the
occsional resolve and the application lives a long time, the connection is
going to be there and over an applicaton's life time with only a few resolves,
there's gonna be an unproportional amount of keepalive messages.

> The keep alive message will only be sent when there is no application
> message exchange. You may specify longer keepidle to reduce traffic (and the
> keepalive is a very small packet).

But c-ares already offers ares_timeout() and the application is supposed to
call ares_process() after the timeout. Why are those not good enough?

-- 
   c-ares -- my preferred DNS asynch resolver library
Received on 2007-08-15