> > There are a huge number of corner cases I did not address,
> > and it was not
> > my intent to be a 100% complete discussion of the use of SSL_read.
> > We are talking of one and specified (renegotiation) case.
> > Nevertheless, I stand by my analysis of his problem.
> OK :-)
> > He called SSL_read with a blocking socket even though he
> > did not want to
> > block. SSL_read has no way of knowing that he doesn't want to
> > block because
> > he lied to it by invoking it as a blocking operation.
> Not HE but OpenSSL developer who created s_client OR
> OpenSSL developer who created SSL_read().
If an OpenSSL developer called SSL_read with a blocking socket in a case
where they did not want to block until application-level data was available,
then that is an error.
> > There will never be any perfectly satisfactory solution to this problem.
> I agree.
> > SSL_read has no way of knowing whether he really wanted to block until
> > application-level data was available or whether he really didn't want to
> > block -- and short of modifying it to call 'select' before it
> > calls 'read'
> > each time or save the blocking state of the socket set it to
> > non-blocking
> > and then set it back, no conceivable implementation off SSL_read can
> > guarantee that it won't block when called on a blocking socket.
> OK, but SSL_read() knows that is doing renegotioation, and sometimes
> SSL_read() returns informations that user should call it again.
> Proper writted application should be prepared (today) to handle this.
> If not - may fail now too.
> So return WANT_READ if renegotiation take place nothing change
> but solves this problem.
Properly-written applications don't make blocking socket operations when
they don't want to block.
> I stand by my analysis of his problem because from may point of view
> library is for user, not user for library :-)
It is this simple -- making a call on a blocking socket when you are
really
thinking in your head "I must not ever block" can *never* be made to work
reliably. Trying to make it seem like it might work a bit more often just
reinforces an extremely bad habit. You can never cover all the corner
cases -- you can never make this work.
If you do not wish to block, you *must* set the socket non-blocking.
That
is *the* mechanism that assures you will not block and it is the *only*
mechanism that does so.
If SSL_read is supposed to be usable on a blocking socket in any
context in
which it is supposed to be guaranteed not to block, it *must* set the socket
non-blocking itself. There simply is no other way to avoid blocking.
Fixing this one case won't fix all the other cases. If you must not
block,
you must set your sockets non-blocking. I'm sorry, but that's a fact.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
