> > If this is really what's happening, it's a bug in OpenSSL. The > > application > > should be able to pass a 1-byte buffer the OpenSSL and get 1 byte of > > decrypted data.
> Consider that when running with the current non-blocking API, once OpenSSL > takes the data out of the socket buffer, both library and application > programmer are basically stuck. No, you are seriously mistaken. > The socket will never come up selectable > for read again, but there is no other way for the application to find out > that there is further data pending internally in OpenSSL. The application should assume that data is pending unless it knows for a fact that no data is pending. > If the intended semantics are "select, then loop reading until WANT_READ > is returned", this is: No. The semantics are: 1) If you want to read data, call SSL_read. 2) If SSL_read returns WANT_READ, then select. If you don't understand this at a fundamental level, then you are totally misusing the OpenSSL non-blocking API. > A) Another significant difference between how read(2) and > SSL_read() operate for nonblocking sockets. Basically all > these differences cause problems. If SSL_select() or SSL_poll() > were provided, it could address this by looking at the internal > buffering; but I think we've argued about the advisability of > providing SSL_select() in the past. Yes, this a difference between how 'read' and 'SSL_read' work. But it's a thoroughly-documented and well-understood one. You may only wait for socket data if the OpenSSL API tells you to. > B) Still problematic even if code is adapted to this API, because > you can't use the arrival of data at the socket to enforce > fairness between peers. Or, rather, you probably can, but only > at the expense of looping over all sockets you haven't yet > seen WANT_READ on -- in the worst case (the case where the peer > writes exactly the application's read buffer size) this at least > doubles the number of calls to SSL_read() for a given workload. I don't follow you at all. You probably have some kind of architecture in mind and you've argued that it's broken. Well, then don't use that architecture, since it's broken. If you're arguing that non-broken architectures are not possible, well, that's just not true. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
