Hello, > > It is very simple - if SSL_read() has to do other work than reading > > application data records (encrypted user data) like renegotiation > > it should return WANT_READ. > > An SSL_read on a blocking socket should block until data can be read, > just > as a regular 'read' on a TCP connection does.
> > Than upper layer may retry SSL_read() after select(). > > For me this is SSL_read() problem and may be simply corrected. > > That makes no sense. Why should the upper layer retry when it already > asked > for a blocking read? This make sense and is used in SSL_read() know. When you have blocking socket SSL_read() may return with indication than is should be called again. This is clearly documented on www.openssl.org and in source code. So this mechanism is used now end this in not true that if you call SSL_read() on blocking socket it must return data or critical error. > > > >That 'read' blocks forever because there was > > > > never any application-level data to read. Sorry, you're screwed. > > > I do not agree. SSL_read() should be corrected. > > If you call SSL_read, an application-level read function, with a > blocking > socket, you are asking it to block until it can read application-level data. You are asking it - but (even now) you may get something else end this is no error. 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]
