On 19 Aug 2002, Ian Holsman wrote:
> I was thinking of doing something like this for quite some time. the
> only issues I can see are keepalives.
There should be no problem with this approach as far as I know. Many
proxies, including open-source Squid, maintain the client-side
connection pool virtually independent from the server-side pool.
> * do they handle things like cookies per request or per
> connection?
Cookies are end-to-end things that are not related to hop-by-hop
connection management.
> * authentication
Same here unless you are talking about some proprietary authentication
methods that require certain connection reuse patterns (but those are
usually not proxied anyway).
> * handling of keepalive timeouts might be tricky
Not in general, AFAIK. You just maintain two connection pools. The
timeout and other algorithms are pretty much the same for each side.
> * ie.. do keepalives keep some state, I am never sure
Not sure what you mean by state here. There is no HTTP state, but,
yes, since a connection may survive several HTTP transactions, there
is some internal state to be kept (e.g., destination address, idle
timer, etc.)
> there are also some other minor problems if you want to load balance the
> backendservers, as that would break.
Yes, but load balancing needs special options and algorithms anyway.
Most of them are not really closely related to idle connection
management.
$0.02,
Alex.
--
| HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
| all of the above - PolyBox appliance
