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
