Re: Connection pinning (patch)

I've attached a re-worked conneciton pinning patch, which I believe fixes
all the previous concerns with the previous connection pinning patch.
Please let me know if you can see any problems with this.

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" <henrik@henriknordstrom.net>
To: "Steven Wilton" <swilton@q-net.net.au>
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.