I'll start by saying that I've done some grovelling through the OpenSSL code to answer this question but the code is pretty unobvious so I'd like a sanity check. The issue is how partial writes are handled in OpenSSL. There are two cases (at least to be concerned with here), blocking and non-blocking. Consider the case where we're calling select() and it says that the socket is ready for writing. However, in fact only 8192 bytes can be written without blocking. (This is pretty common since a lot of Unix kernel buffers are 8192 bytes long). BLOCKING First, consider the case where the programmer requests a write < 16384 bytes. As a consequence, it gets sent as one record which is sent down to ssl3_write_pending(). It's a little hard to determine what's going to happen at this point but clearly no more than 8192 bytes can be written without blocking. Assuming that BIO_write() ultimately behaves like write, the first write will be <= 8192 bytes. However, ssl3_write_pending() loops around BIO_write(), and so the second BIO_write() will block. This is bad because we've just blocked even though select() says we won't block. NON-BLOCKING This time, the second call to BIO_write() returns a would block error which propagates up to the caller. As I understand it, the caller now has to call SSL_write() with the same buffer that he originally called it with unless SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER was set. It appears to me that the buffer can be extended and the API will still work. However, this seems to have nasty consequences since SSL_write() will always return a block error unless it can write the entire buffer. Correct? Thanks, -Ekr [Eric Rescorla [EMAIL PROTECTED]] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
