Dan Kegel wrote: > > Dr S N Henson wrote: > > Dan Kegel 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. You can prohibit renegotiations by the client though. The speed of symmetric ciphers might be a problem for general I/O, but nowhere near as bad as the slow asymmetric ones. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
