On Mon, 2002-11-25 at 23:34, Hugo Duncan wrote: > Hamish, > > On 25 Nov 2002 17:17:41 +0000, Hamish Mackenzie <[EMAIL PROTECTED]> wrote: > > On Mon, 2002-11-25 at 15:43, Hugo Duncan wrote: > > > A write on an ssl stream can > > > > block attempting to read from the underlying socket (and vice-versa). > > > > > > Not sure I fully understand this. Could you elaborate please. > > > is want_read equivalent to "Would Block On Write" ? > > > > want_read indicates that the call is blocking because there is no data > > to read from the socket at present. In the case of an ssl socket this > > could be returned from recv or send. want_read and want_write could > > also be returned from ssl connect. > > presumably that should be > "want_read indicates that the call is blocking because there is data > to read from the socket at present" without the negative?
No it is the SSL layer is saying "I wanted to read but I couldn't without blocking". You must retry the call when there is something to read. Here is a paragraph from the openssl docs... If the underlying BIO is non-blocking, SSL_write() will also return, when the underlying BIO could not satisfy the needs of SSL_write() to continue the operation. In this case a call to SSL_get_error(3) with the return value of SSL_write() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. As at any time a re-negotiation is possible, a call to SSL_write() can also cause read operations! The calling process then must repeat the call after taking appropriate action to satisfy the needs of SSL_write(). The action depends on the underlying BIO. When using a non-blocking socket, nothing is to be done, but select() can be used to check for the required condition. When using a buffering BIO, like a BIO pair, data must be written into or retrieved out of the BIO before being able to continue. -- Hamish Mackenzie <[EMAIL PROTECTED]> _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
