Henrik Thuermer wrote:
At 15:20 17.07.2006 -0700, you wrote:
Yes, I know that. But in our case there is no renegotiation: SSL_write
never returns an error and if the SSL_read return value is below zero
SSL_get_error returns only WANT_READ. In that case there was never someting
in the outgoing BIO. Therefore I assume that simply means: There is no more
data to decrypt.
Irrespective of whether you are doing SSL_read or
SSL_write... That is why you have to check for pending
write during a SSL_read and vice versa in the non
blocking case.
We check for pending read/write only if SSL_read/SSL_write return value is
below zero. Maybe we should check after every SSL_read/SSL_write
irrespective of the return value?
You only have to check for pending write when you've temporarily
disabled the mechanism to drive writes with writability indication from
the BIO/fd (select/poll/write). Since at all other times for
non-blocking I/O surely you want it driven by writability indication ?
Then when you are checking you are only checking to release this special
condition, so you can go back to non-blocking mode driven by writability
indication from the BIO/fd.
This can be done with a flag against your client connection, you set it
when you call SSL_write() and get back -1/WANT_READ.
Then in your readability indication callback you call SSL_read() then
providing you dont get a fatal error condition from it. If the flag is
set (meaning your writes are not driven via BIO/fd writability
indication at this time) you call SSL_write() again. If SSL_write() not
longer returns WANT_READ you can clear your flag and resume normal
operations again with writes driven by writability indication.
It also theoretically possible for the reverse situation to be true as
well, but its statistically less of a problem because of the natural
data flow that occurs.
I'm a little interested in the three_byte_header situation you raised.
If I understand the outline correctly you were questioning whether it is
safe to mix calls of SSL_read() and SSL_write() because when you looked
over the SSL library code you saw a variable that both the read
machinery and write machinery were sharing. You then thought it maybe
possible for the machinery to get confused.
I believe its 100% safe to mix calls to SSL_read()/SSL_write() in any
order upon a valid SSL* handle from the same thread of execution. If
you have identified a problem that makes that claim untrue then that
smells like a bug.
So is the three_byte_header thing a misunderstanding of the source or a
genuine concern ?
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
