Bodo Moeller wrote:
> On Mon, Nov 13, 2000 at 07:16:39PM -0800, Dan Kegel wrote:
> > Nonblocking network I/O is tricky with the current API, but doable.
> > I've got working code for that, and there are good examples now.
> > Nonblocking crypto is another matter; it would be a real pain, and
> > there are no examples showing how it might be done.
>
> Non-blocking crypto can't be done right now, but there could be a new
> SSL_get_error return value saying "call the previous function again".
> (There could be one mode where cryptographic operations are always
> completed in one go, one mode where they may be split, and even modes
> where public key cryptography or all crypto is avoided completely
> until switched on again.) The current BIO API means that applications
> don't have to handle handshakes (including renegotiation) explicitly,
> which is why I don't believe that non-blocking I/O is trickier
> now than it would be with different APIs.
I don't think we need nonblocking crypto; it would be enough to be able
to shunt the crypto off into another thread. That's what my API proposal
was about.
> It should be possible to implement something close to what you
> describe at <URL http://www.kegel.com/ssl/api.html> on top of the
> current SSL API with new SSL_get_error return values addeed, using
> either a BIO pair or memory BIOs.
But why would you want to? The whole point of my API was to reduce
the complexity of the innards of OpenSSL, and to make it easy to
shunt crypto stuff off to another thread. Implementing my API on
top of the current OpenSSL API would be absurd.
- Dan
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
