Hello, > > > 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. 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.
> > 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. > 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 > 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. 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. Best regards, -- Marek Marcola <[EMAIL PROTECTED]> ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
