On Thu, Jul 31, 2008 at 05:14:09PM -0700, David Schwartz wrote: > > Let me just state this one more time one other way to help people wrap their > brain around it. The OpenSSL library is a black box. You are not supposed to > look inside the black box. > > If you want to get decrypted plaintext from the black box, the black box may > or may not need to read data from the socket to get it. You don't know, and > you're not supposed to know. When you want to read data, you're supposed to > call SSL_read.
Perhaps if you intended to have an API that didn't act like Unix read() and write() it should not have used those names... ...and yes, I'm aware that it works like read() and write() until you set non-blocking I/O. Then the semantics are (as you've just pointed out) different. Care to explain why you can't discuss how the API might or might not work without throwing around gratuitous insults? This last message to which I'm responding is merely condescending; the previous was downright insulting and offensive. I can't see how that helps anyone. And after all, it's not like the current mess of a non-blocking API is your design nor your code, at least not as far as I can tell. The problem with "read until there's no more" semantics is that you can't really use them to do fair I/O in a traditional Unix single-threaded event-driven model. If I have no way to find out whether there might be more I/O available to drain except to try to drain it, I have to either: 1) Service each client in turn whether or not they're ready, since I can't tell whether they're ready without paying the whole cost of the read() and the decryption or 2) Fully drain everything each client might have cared to write me each time I find that he's ready at all. This allows a single client to consume as much of a server's time as it cares to, to the detriment of the others. The traditional Unix non-blocking semantics where you can stop reading whenever you like and sleep (via select or poll on _many_ streams at once) to find out who's got more for you don't have this problem. So many, many event-driven Unix applications are written to do precisely that. If I'm hearing you correctly you are saying that not only cannot one do that with OpenSSL, one ought not want to do such a thing. I do not grasp why. Incidentally, if one's not intended to peek under the hood, again, I ask why OpenSSL _encourages_ this by providing no sleep-for-IO mechanism which does not, in fact, _require_ peeking under the hood. Furthermore, the SSL_read() documentation, which I was so foolish as to use as my guidance to this portion of the API, explicitly says to use select() to find out if I/O's available after receiving a WANT_READ or WANT_WRITE error. You _cannot do that_ without peeking under the hood, because you of course must break the abstraction and get the BIO's file descriptor to feed to select! I can think of a number of ways to support applications that would like to do something like typical Unix event-driven multiplexed I/O by augmenting, rather than altering, the existing API. But if they're just going to be met by a barrage of condescension or insults, I'm not sure it's worth bothering to discuss... Thor ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
