Graham Leggett wrote:
>
> Greg Stein wrote:
>
> > This is the Right Way to solve it. The proxy should hold a pool of
> > connections to other servers. When a request comes in, it looks in the pool
> > for an available connection, pulls it from the pool (so it won't get used by
> > two requests simultaneously), runs the request with it, if the connection
> > remains open, then puts it back in the pool.
>
> Ok - makes sense.
>
Yes, indeed. The binding between outbound and inbound connections exists
only for the lifetime of a given connection. Beyond that, there
shouldn't be an association.
> > Further, using a conn_rec for an *outbound* connection is just wrong. Yes,
> > there is a tiny bit of similarity. But things like base_server,
> > vhost_lookup_data, remote_logname, double_reverse, local_ip, local_host, etc
> > ... none of those apply whatsoever to outbound connections.
>
> Using a conn_rec for an outbound connection has allowed us to use
> filters - which has cut down the proxy code by an enormous amount.
> Outbound connections are almost identical to inbound ones - once the
> status or request lines have been removed both outbound and inbound
> requests are virtually the same.
>
Greg, are you suggesting we need to reimplement filters for outbound
connects (in general) to gain their benefits? That just sounds like too
big a bit of reusability to toss. I mean, it sure looks to me like
there's at least as much stuff in a conn_rec that an outbound connect
can use as there is that it can't. And what's not used is a matter of
bytes per connection, not a large amount of wastage.
--
Chuck
Chuck Murcko
Topsail Group
[EMAIL PROTECTED]
