> If the SSL implementation works in this way then trying to shoe-horn SSL > into a similar 3 argument API as the kernel was a bad design decision.
I agree. In other words, the nature of SSL demands a more complex API than TCP. > Its probably a bit late in the game to go changing the SSL_write() call > so maybe SSL_write_foobar() could be implemented over the top of the > existing protocol infrastructure. Honestly I think a better job of mimicking TCP's semantics is preferable. OpenSSL should be able to handle its own send buffer flushing and receive buffer filling, in the background without me having to ask it, just like TCP does. This can easily be done with OpenSSL creating its own service threads. For single -threaded builds, it can also be done, it's just not as elegant. Another example is OpenSSL prohibiting a concurrent SSL_read and SSL_write on the same connection. Yes, this is consistent with what other libraries do, but it's not what TCP does. I think a library should be capable of making SSL look as much like TCP as possible and that this should probably be the default behavior. > It would make sense to store the previous write address, the previous > length and checksum the previous data and validate all these things in a > debugging build of OpenSSL so that no application designer could get > away with misusing the API because OpenSSL validates the usage rules. > This way the error is given at the point when the error was made not at > some unspecified point in time later. Definitely. If a requirement can easily be violated, can cause subtle problems when it's violated, and can easily be checked for in a debug build (and even detect cases that won't always cause problems in the release build) that check should definitely be there. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
