On Wed, Mar 05, 2008 at 12:10:04PM -0500, Geoff Thorpe wrote: > > I was not involved in the discussion so am not familiar with the > arguments. However I agree that SSL_[poll|select]() would be unwise > because it presumes to make the SSL/TLS stack transport-aware, whereas > the BIO scheme is an honest (if sometimes inelegant) attempt to leave > the stack transport-agnostic. SSL/TLS can be fed data on all sides
But you can't stay transport-agnostic and actually use the stack in non-blocking mode now. You *must* extract the underlying file descriptor and sleep on it with select/poll, which effectively forecloses any option of using some other asynchronous event mechanism at the same time except heavyweight signals, under Unix at least (and using signals that way will butcher performance; I have benchmarked this). > > This API also *already* requires any operations that would block to be > > reissued at the SSL layer by retrying exactly the same operation again > > after the file descriptor for that session comes up ready with select > > or poll. > > Sure, but that's because you are *not* suspended miles down a code path > that you need to find your way back to. It means the state-machine has > advanced as far as it can go and to advance further, you will need the > presence of either input on your read BIO or some drainage on your write > BIO. Those events are on the exterior of the SSL/TLS state-machine and > represent a stable state, the code-paths exit cleanly in that state and > when progress is possible, we will go down new code paths to do new > work. This is not the same as trying to pick up where you left off way > down a code-path that has not been designed with suspend-and-retry > semantics in mind. Eg. if you were calling SSL_read() when you got a > WANT_WRITE, but you then called SSL_write() - it should *not* crash. Should not, or does not? I think you're a bit optimistic about the current implementation, for what it's worth. Failure to retry the exact same operation, now, causes chaos, including data corruption. > What you're describing, about being able to replay your way down a prior > code-path, would be very hard to make robust in an equivalent way. For what it's worth, I and my coworkers have done this, to an originally openssl-derived code base, which still retains BIO, etc., and it was not too hard to make it work at least as well as the current read/write suspension does. > > So, given my "note first" and "note second" I believe I have established > > that, to do non-blocking I/O in a single-threaded application with OpenSSL, > > one must already: > > > > 1) Dip beneath the SSL abstraction layer to get the file > > descriptor for each session. > > No, this is one form it must be able to take, but this is not *the* > general method for OpenSSL to support. But it is the only way that works now. And that is the problem: the current API, I think, essentially precludes the simultaneous use of some other notification mechanism for another type of asynchronous events, because _while_ you are sleeping for some SSL sessions in select/poll for I/O ready on their file descriptors, you can not be doing anything else. It all gets easier with multiple threads, of course -- but it is precisely single-threaded, "traditional Unix" event-driven applications that are the consumers of the existing non-blocking API. I think you're right; we do largely agree on, given the opportunity to start over from scratch, a new API for this ought to look. But I am just highly skeptical that it's possible to do anything cleaner than the (admittedly ugly, but ugly in the same way the current API is ugly) scheme I've described, and actually keep existing single-threaded code written to the non-blocking API working with non-blocking I/O. You have to be able to wait for I/O completion on some sessions and crypto completion on others (or, ideally, both, for each direction of one session!) at the same time -- and the basically mandatory use of select/poll in the existing API precludes using anything else to wait on the crypto. At least, so it seems to me (though I am eager to see what you come up with). Thor ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
