On Tue, Jun 22, 1999, [EMAIL PROTECTED] wrote:
> Ben Laurie <[EMAIL PROTECTED]> writes:
>
> > [EMAIL PROTECTED] wrote:
> > >
> > > You may want to consider a solution from F5 Labs or HolonTech that will
> > > always "route" data to a particular server based upon SSL session
> > > id. Otherwise, you'll have a boat load of re-negotiations going on. Not that
> > > I endorse any of these products, but these are the few that I know of that
> > > do this.
> >
> > Actually, that's one of the reasons I wrote Apache-SSL's gcache as a
> > socket-based service (so you can distribute sessions across
> > load-balanced servers).
>
> Yup. And that's why I wish Ralf hadn't taken it out of mod_ssl. A threaded
> gcache with an in memory cache would be cool.
There were good reasons why I kicked it out in the past. But the suggestion
to reintegrate it is ok, of course. The hint of threading actually makes it
interesting again. I'm currently finishing my new multithreading library NPS
(see http://www.engelschall.com/sw/nps/ when you're interested in my latest
coding) and you're right: gcache could benefit a little from threading, too.
But when I reintegrate gcache again for mod_ssl 2.4.0 I'll do it different: It
will not again be spawned and driven by Apache itself. That has too much
problems and isn't stable enough for a reliable service IMHO.
But we could just create a "SSLSessionCache gcache://hostname:port" which can
be added _IN ADDITION_ to a standard SSLSessioCache directive (the same way
SSLCertificateFile is allowed multiple times in mod_ssl). Then mod_ssl before
failing to lookup sessions connects to an externally running gcache. This has
to be started before manually, of course. And for speedup reasons this gcache
could use threads, yes.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
