On Sun, Jun 11, 2006 at 09:51:25PM +0200, Marek Marcola wrote:
> I repeat - application want to block but only on user data, you are not
> talking of this case.
It looks like you are repeatedly making the same mistake, if one is
willing to block for user data, by making a blocking SSL_read() call,
one is consequently willing to also block on handshake packets that
precede said user data. By making a blocking call one is saying that
the application demands remote input at that point in the protocol and
is willing to wait for it indefinitely.
A "socket ready for read" condition is not an appropriate indication that
it is the peer's turn to send user data. Turn-taking is up to the higher
level protocol. If the protocol is not half-duplex, the application must
use non-blocking I/O. One must not make blocking SSL_read() calls unless
one means it.
> I repeat again, application want to block, but only on user data - all SSL
> related work should be handled internally by library - if SSL work need
> some time to do something - OK, no problem - if even want to block for
> some SSL work - OK - after that (like now) gives only hint to call it
> again. Fixing this removes this dependency.
Sorry, I believe you are mistaken, you are proposing to fix poorly
written non-blocking applications by breaking correctly written blocking
applications. This is not acceptable. Please take some time to think
through all the use cases beyond the immedeate issue that is motivating
this thread.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
