This version moves some of the pconnPush logic around to make it similar to the pconnPop logic (and also moves the TPROXY case to handle peers better), and at the same time it will always store the destination host and port for a pinned connection (even when the conneciton is going to a peer). It also does a pconnLookup for pinned client-side connections before going through the peer selection logic, and bypasses peer selection if it detects a pinned server connection for the request. Finally, I've added server and client fd information into the fde struct, and then made comm_close close all server pinned fd's when it closes the client fd.
It works for me both when I set 4 parent caches, and where I have no parents defined.
Regards Steven----- Original Message ----- From: "Henrik Nordstrom" <[EMAIL PROTECTED]>
To: "Steven Wilton" <[EMAIL PROTECTED]> Cc: <squid-dev@squid-cache.org> Sent: Friday, May 26, 2006 8:53 PM Subject: RE: Connection pinning (patch) fre 2006-05-26 klockan 09:22 +0800 skrev Steven Wilton:
The current code will not that there is a pinned connection if a peer is used, as the pconn connection is stored under the key of the peer and not the requested site. Even with the proposed changes it won't work if there is more than one peer. To work when there is more than one peer the peer selection logics must me shortcircuited.Will the current 2.6 code handle this case gracefully?The current code will only work in the direct case, not when using even a single parent. I haven't analyzed in detail what will happen, but it ain't going to be good..Wouldn't the connections need to be pinned when the server indicates connection oriented auth so the client's request can go back to the same server-side connection?Exacly, but only in response to client initiated connection oriented auth. Hmm.. actually not, the criteria is the client side, not server side. Connections need to be pinned when the client indicates connection oriented auth. If the client request was not carrying any connection oriented auth then the message is just an announce that the server is willing to do connection oriented auth. At least in the NTLM and Negotiate schemes we care about. Thinking. The correct method is to enable pinning of both sides as soon as connection oriented auth WITH details (not only the scheme name) has been seen from the client. From this point on until the server connection is gone or the client requests a different server the requests should short-circuit peer selection and always end up at this connection, which may either be a direct connection or a connection via a specific peer. If the server connection is lost then the process restarts and the client connection goes back to unpinned. A similar scheme is needed for connection oriented proxy authentication, but here the condition on the requested server does not apply.
pinning-2.6v2.patch
Description: Binary data
