Dr S N Henson wrote:
> > > > I'm doing it; right now, I have a single network thread doing all normal
> > > > networking *and* SSL; after I write the load tests that demonstrate
> > > > how woefully inadequate that is :-), I'll split that into two threads:
> > > > one for doing the SSL accept / connect stuff, and one for all other
> > > > networking including bulk SSL. (I have yet other threads for disk I/O.)
> > > > Hope that will suffice, otherwise I get to do a little refactoring, or worse.
> > >
> > > The problem with that is that a client can renegotiate a session at any
> > > time.
> >
> > Oh, right. That's a bit of a problem. A big problem, actually.
> > Is there any provision in OpenSSL for notifying the application
> > when you're about to do heavy number crunching, so the work
> > can be moved to a different thread? I doubt it.
>
> Currently there is no non blocking crypto interface (which is one way of
> achieving this) though this has been discussed in the past.
I wonder if the engine interface would be helpful here;
conceivably I could define a crypto provider that would just
be the default one but running in another thread.
I have a sinking suspicion it's a blocking interface, though,
which wouldn't help a bit.
> You can prohibit renegotiations by the client though.
Hmm. That and limiting the connection's lifetime might do it.
> The speed of symmetric ciphers might be a problem for general I/O, but
> nowhere near as bad as the slow asymmetric ones.
Agreed.
- Dan
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
