I am trying to rework a rather dreadful vendor-supplied OpenSSL variant library to support event-driven operation in a clean way.
Unfortunately, the underlying device does "macro operations" that can't be accomodated by the current -engine interface. But I can live with maintaining a whole separate library that conforms to the OpenSSL API -- I have to for two _other_ vendors' devices already -- if I can get the code and interfaces reasonably clean. While working on this I have noted what seems to me to be an opportunity for improvement in the existing OpenSSL API, or perhaps more rightly an interface that should be in the API but is presently missing. Though we have SSL_read() and SSL_write() and a non-blocking mode for SSL sessions, we lack SSL_poll() or SSL_select(). At first glance this may seem unimportant -- the documentation simply instructs the user to peek inside the context structure, grab the underlying fd, and call select() or poll() on it himself, being careful to always check for read *or* write since SSL can require network writes to complete SSL reads -- but, actually, when working with hardware crypto that can return results asynchronously, it's a problem. The issue is, basically, that for an application that's managing many SSL sessions at once (imagine, perhaps, 1 or 2 thousand) we are likely to block the entire application waiting for a command to a crypto accellerator to finish, when we could be sending or receiving network data for other sessions in the meanwhile. This happens even with engine but is particularly severe if the OpenSSL API is actually supplied to the application by a modified library that can do larger, more expensive crypto operations in one shot. In essence, you can't run fully non-blocking because you can't do the _cryptography_ in a non-blocking way. What you'd really like, here *and* for engines, I think, is the ability to add one or more fds to wait on behind the application's back. 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. And it would also avoid a profusion of incompatible APIs addressing this on the part of SSL accellerator hardware vendors, which is an actual problem causing user lock-in to particular hardware vendors now. I should also mention that the vendor APIs I've seen for this are uniformly quite poor, while SSL_poll() or _select() would be pretty clean and conform generally to the way the existing API works. -- Thor Lancelot Simon [EMAIL PROTECTED] "All of my opinions are consistent, but I cannot present them all at once." -Jean-Jacques Rousseau, On The Social Contract ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
