> I'd say that has very little to do with BIOs and more to do with the
> fact that the public key API has no concept of "non blocking operations"
> and this has filtered down to the SSL API.
>
> It may be possible to actually do what you want through some of the SSL
> state callbacks but I haven't looked at that in much detail. Something
> like tracking the states and then moving the execution to another thread
> when the state involve expensive crypto operations then shifting it back
> when they have finished.
adding support for non-blocking public key operations to SSL handshake
requires a lot of changes. first, one must add new states to SSL
statemachine for public key operations. then we need a non-blocking
interface for public key operations.
right now BIO's are used for all non-blocking data sources (sockets, SSL).
i think that public key operations should have a BIO interface too.
then we can add third sub-BIO to SSL statemachine: a public key BIO.
this will make event handling even more complex: right now event handling
is left to application and everyone must fight with select and
SSL_get_error. when we add non-blocking public key crypto, then we create
another source of events.
i think that adding generalized event management into OpenSSL is good
idea. i have in mind something like BIO_select, which looks like and works
like a ordinary select, but accepts a set of BIO's instead of file
handles. BIO_select calls every BIO's statemachine function, which fills
out FD_SETs for real select function and finally calls a real select
function with appropriate FD_SETs. timeout management and even signal
management can be added to this function. under Windows we can
transparently use Windows-specific event management functions like
WSAEventSelect and WaitForMultipleObjects to overcome the limitations of
select.
arne
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
