> > Properly-written applications don't make blocking socket
> > operations when
> > they don't want to block.
> Properly-written application have right to use consistent way to
> use blocking
> socket - they want to block only on user data - they are not interested
> what is going on in SSL layer and library should assure that.
> Renegotiation is special case and (now too) have special treatment
> in OpenSSL so if you do not agree with that you may fix this
> in next release.
If SSL_read ever blocked when there was application-level data
available,
you would have a legitimate complaint.
> > > 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.
> I repeat - application want to block but only on user data, you are not
> talking of this case.
That's fine, SSL_read will never block when there is user data.
> > 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.
> One again - I want to block, but I am not interested on low level
> SSL stuff
That's fine, you are blocking. So you should be happy.
> > you must set your sockets non-blocking. I'm sorry, but that's a fact.
> I repeat again, application want to block,
> but only on user data
That's fine. I agree that SSL_read on a blocking socket should block
until
user data is available.
>- 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.
I can't follow your logic here. SSL_read on a blocking socket should
work
like read on a blocking socket, blocking until some data can be returned to
the caller. Cases where it returns early (such as on receipt of a signal)
are fine, but the caller should expect it to block until data is available
and should not call it unless they know from application-level
considerations that data will be available.
Applications that call a socket function or SSL function thinking "I do
not
want to block" *must* set the socket non-blocking. Nothing OpenSSL can do
will change that,
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
