> I'd agree with you if it was not working consistently.
It's a race condition.
> But in most cases
> blocking SSL_read returns helpful WANT_READ. My understanding is that
> WANT_READ return from SSL_read is especially for avoiding the
> deadlock I'm
> running into.
You would be correct if your socket was non-blocking. But because it's
blocking, when SSL_read calls 'read', it blocks, possibly forever. The
problem is that if you call SSL_read with a blocking socket, it will block
until it has some application-level data for you. But you called it when
there was no application-level data.
> Why else would a blocking SSL_read return WANT_READ??
I'm not even sure if this is a blocking SSL_read or not. You called
'select'. You have some horrible hybrid between blocking and non-blocking.
> I'm
> asking it to read data and it comes back and says "I can't help you, I'd
> have to wait for data first". I think what it is trying to say is "I
> can't help you right now because I don't really have data to read even
> though you probably had reasons to beleive that there was some data
> available".
> Either way, there seems to be a bug either in the lib itself or in
> s_client.
How can it know what you want it to do when you lie to it? You called a
*blocking* SSL_read, whose sole job is to block until it gets some data for
you. But there is no data for you. So it blocks, like you asked it do when
you called it with a blocking socket.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
