> 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 [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
