On Mon, 2008-06-16 at 20:54 +0200, Daniel Stenberg wrote:
> On Mon, 16 Jun 2008, Phil Blundell wrote:
>
> > One of our applications has a requirement that idle TCP connections should
> > not be left hanging around for more than a minute. Right now, the multi
> > conncache seems to be prepared to leave connections open indefinitely unless
> > curl_multi_cleanup() is called or cache pressure forces some to be evicted.
>
> Ah, yes. Similar things have been requested before so I think it is a fair
> idea to persue.
>
> A few things on the actual patch/approach:
>
> o it needs to do Curl_disconnect() on the connections, not just conn_free().
> The lib/url.c:Curl_ch_connc() function should give lots of clues

Thanks for the feedback. I couldn't immediately figure out how to make
Curl_disconnect() work for connections that weren't associated with any
easy handle; it seemed that conn->data just pointed off into oblivion in
that case, which led to a crash somewhere in the hostcache code. Can
you give me any further hints on that?

> o in a typical application that wants to keep connections alive no longer than
> 60 seconds, it would need to call this function very often since the app has
> no idea about the current status of the connections. There could be 20
> connections timing out in 2 seconds or one in 59 seconds. Perhaps it would
> make sense to let the function return the time it currently knows until the
> next connection is about to timeout given the timeout value in the argument?
> That way the application might be able to actually hold off calling the
> reap function for a while - but it doesn't have to.

Yes, good idea.

> An alternative approach is of course to do the entire timeout-check and
> closing of idle connections internally. That solves the "calling it too
> often" problem and it also helps us from adding a new function (new
> functions are a lot more trouble than just new setopt options).

Yah, that was my first thought in fact, but it seemed like it would be
rather harder to implement this way. You'd need to either arrange for
the application to call curl_multi_perform() at the right moment or do
something with alarm(), and neither of those seem entirely
straightforward.

> o curl_multi_reap_idle_connections() feels like a slightly too long name, how
> about just curl_multi_close_idle() ?

Yup, fair enough.

> o there was no man page added for the new function
>
> o it would be really cool with a test case for it!

Noted. I guess I'll see if I can write those once we've established
what it is actually going to do. :-)

p.
Received on 2008-06-16