Re: [squid-users] tproxy2 patch for squid3

From: Henrik Nordstrom <henrik@dont-contact.us>
Date: Sat, 29 Jul 2006 16:35:47 +0200

lör 2006-07-29 klockan 15:47 +0200 skrev Jan Engelhardt:

> If multiple client-proxy streams are multiplexed into one proxy-webserver
> stream, we anyhow have a hard time to bind to all address at once.

???

The binding is only done on connection setup, not per request. It's TCP
so it can't be done in any other way.

> Does this explain why some client-proxy connections time out after 30
> seconds?

No. That's something else entirely.

The problem I meantioned is more of

1. Client A makes a request, connection to web server is created and
tproxied as A. It receives response from server. The proxy->webserver
connection is then released into the idle persistent connections pool.

2. Client B makes a request to the same server. Squid finds the idle
persistent connection and reuses it, avoiding to have set up a new
connection. This will therefore use the address of A.

And to make the situation slightly more complex further illustrating the
problem:

3. Client B sends another request while waiting for the response on the
first. This gets a new connection (no idle available) and is tproxied as
B. Response received.

4. Client A now sends another request before B has finished in 2. Squid
finds the idle connetion set up in 3 and A's request is now sent as if
it came from B.

The relevant parts of the code to fix this is in FwdState::pconnPush and
FwdState::connectStart fwdPconnPool->pop().

> Other places where commConnectStart may be called from would be
> falsely tproxified, that was the idea.

Easily handled as the src argument then defaults to NULL in your
prototype..

Regards
Henrik

Received on Sat Jul 29 2006 - 08:35:52 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Aug 01 2006 - 12:00:02 MDT