On Wed, 30 Sep 2009, Joshua Kwan wrote:

> 1) If all the connections have actually been severed on the socket level,
> why is the connection cache still full? Should it be empty by the point
> where all sockets have been closed and traffic has ceased? Or does the
> connection cache hold symbolic connections (i.e. cookie and authentication
> state preserving but not socket preserving?)

The connection cache should only keep actually open connections. As soon as
libcurl detects a connection not being alive anymore it should be closed
properly and removed from the connection cache. Anything else is a buggy
behavior.

But of course, the connections might've been alive when they were put into the
cache and they all died while in there. Oh, but you said they were marked
'inuse' right? That can't be right as only connection still be actually in use
should have that set. As soon as they are "returned" to the cache they should
not be inuse anymore.

> 1.5) Our program uses the multi API with the socket_action workflow and it
> seems like we could plausibly responsible for keeping cURL state consistent
> with what sockets are actually open or closed. Could this be the source of
> the problem?

Hm. Well it could possibly be the case if your app somehow doesn't tell
libcurl about the closing of the sockets and the terminating of the request,
so that the socket is atually closed (as you see) but libcurl is still
thinking the requests/connections are alive. This is just me speaking out my
mind loud, I'm not exactly sure how it would occur.

> 2) Assuming #1 is working as designed, we need to preserve NTLM state even
> if the initial NEGOTIATE results in a closed connection after the response
> comes in. I think the state machine might need another value to represent
> this so the state can be copied over to the new connection.

No. NTLM is made for and only used for negotiating authentication for the
_connection_. If the connection is closed there's no NTLM state left necesary
to save as it needs to be restarted on the next connect.

The problem is rather that we can start a new connection and go with NTLM
there but we can't keep it in the cache so we can't complete the NTLM
negotiation. You can of course work around this by inreasing the connection
cache size, but the actual problem is problem seen by this sympthom. The
connection cache really shouldn't get full of inuse connections, and if that
happens when it is about to do NTLM I think a better behavior would be to
instead fail that transfer entirely and as early as possible as it simply
won't be able to proceed with that.

> The whole thing wouldn't be a problem if the connection cache weren't always
> full, or if the NTLM subsystem had better support for a disconnection right
> after the CHALLENGE comes back. url.c:2639 looks like it contains code that
> will help to preserve the NTLM state over different connections but perhaps
> it isn't enough as-is?

Uhm, url.c:2639 of what libcurl version?

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html