RE: Connection pinning (patch)

From: Steven Wilton <swilton@dont-contact.us>
Date: Wed, 7 Jun 2006 07:59:55 +0800

 

> -----Original Message-----
> From: Henrik Nordstrom [mailto:henrik@henriknordstrom.net]
> Sent: Saturday, 3 June 2006 6:39 AM
> To: Steven Wilton
> Cc: squid-dev@squid-cache.org
> Subject: Re: Connection pinning (patch)
>
> tor 2006-06-01 klockan 19:46 +0800 skrev Steven Wilton:
> > 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.
>
> Don't seem to handle the case where the server FD is closed first very
> well.. or at least I don't see any code unregistering this FD from the
> client fd on close..
>
> Also I am still not convinced we really need to support more than one
> pinned server FD per client connection. Is the clients really
> expecting
> to be able to switch between multiple authenticated sessions to
> different servers on the same connection?
>
> Regards
> Henrik

If the server fd is closed, the client pconnLookup will fail, and the client
will re-connect.

The code in comm.c uses the timeout handler to cause the pconn to close when
the client fd is closed. If the server connection has been closed, the
timeout handler will be NULL, so there will be no work to do when the client
fd closes. It also record which client fd each server fd has been pinned
to, which will avoid any problems if the server fd is re-used on another
request.

I have run tests, and can confirm that when proxies are set in the web
browser, the same client-side fd will be used for multiple requests to
different server-side fd's. There are 2 clean ways to handle this, we can
either shut down any existing pinned server connection if another request
needs to be pinned to the same client fd, or allow multiple server fd's to
be pinned to the same client fd. You're probably right that clients will
not usually be actively using multiple pinned connections simultaneously,
but because it is a possibility, and it's easy enough to make work, I don't
see the harm in letting it work.

Steven

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.2/356 - Release Date: 5/06/2006
 
Received on Tue Jun 06 2006 - 18:00:02 MDT

This archive was generated by hypermail pre-2.1.9 : Fri Jun 30 2006 - 12:00:02 MDT