Boost logo

Boost :

From: Hamish Mackenzie (hamish_at_[hidden])
Date: 2002-11-25 19:15:24


On Mon, 2002-11-25 at 23:34, Hugo Duncan wrote:
> Hamish,
>
> On 25 Nov 2002 17:17:41 +0000, Hamish Mackenzie <hamish_at_[hidden]> 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 <hamish_at_[hidden]>

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk