On Mon, 15 May 2006 22:07:17 -0400 (EDT), "Mikhail Kruk" <[EMAIL PROTECTED]> said: > Assuming that we are talking about a regular tcp non-blocking socket, the > answer is yes. SSL_read() is just telling you that your request can't be > satisfied at the moment and should be retried after more data is read > (written) from (to) the socket. You don't have to do anything in > response > to that. The usual thing to do is to block using select() or something > similar, but you don't have to. Calling SSL_write is OK to. Of course it > will most likely fail with the same error, so maybe you do want to > select(). But it is ok (as in "will work", not as in "The Right Thing To > Do") to just blindly keep trying calling SSL_read and SSL_write.
In fact I'm using a custom BIO to interface between OpenSSL and some custom buffer structures. If I hadn't misread the protocol, for application data, SSL_write() should be able to proceed even when a SSL_read() returned WANT_READ. But what about rehandshake? If the SSL_read() returned WANT_READ during rehandshaking, will a SSL_write() at this moment conflict with it? -- http://www.fastmail.fm - Send your email first class ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
