RE: Connection pinning (patch)

From: Henrik Nordstrom <henrik@dont-contact.us>
Date: Fri, 26 May 2006 14:53:36 +0200

fre 2006-05-26 klockan 09:22 +0800 skrev Steven Wilton:

> Are you saying that, if this request is assigned to a different parent cache
> (which can happen randomly), then the current code will never find the
> persistent server-side connection?

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.

Regards
Henrik

Received on Fri May 26 2006 - 06:53:43 MDT

This archive was generated by hypermail pre-2.1.9 : Thu Jun 01 2006 - 12:00:04 MDT