> If we were to add SSL_poll() (my preference) or SSL_select()
> (perhaps more portable) to the API, the OpenSSL library could add
> events to the set the application is waiting on -- so it could
> wake the application up when crypto requests had finished and
> SSL_read()/SSL_write() were possible. By default, these functions
> could even #define or inline away in the headers to the underlying
> OS poll()/select() -- but this would provide the opportunity to
> replace them via poll/select methods in engines in the future.


Multiplexing the cryptographic operations isn't the only issue. Another
issue is the one I posted about a few days ago where you SSL_read gives you
a 'WANT_READ' indication even though it made forward progress making an
SSL_write possible.

I think an ideal solution would be to solve all of these issues with one SSL
I/O multiplexing API. For example, if you added an SSL session to the write
set, it would ensure the 'poll' broke out when it might be possible to write
to that session, whether or not that required socket I/O.

I also think building it around 'poll' makes the most sense. The application
should have a way to add its own file descriptors to the poll sets before
blocking in 'poll'.

Perhaps some kind of SSL poll set. You could add either SSL connections or
raw file descriptors to it. Then when you call SSL_poll, it checks if any of
the SSL connections can make forward progress, does whatever it needs to
setup blocking on those connections and any file descriptors you add to the
SSL poll set, and then calls 'poll'. It removes from the return set any SSL
file descriptors and properly modifies the SSL poll set to tell you that
forward progress is possible on those SSL connections.

DS


__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org