RE: [boost] Re: Socket errors

From: Darryl Green (Darryl.Green_at_[hidden])
Date: 2002-11-25 19:55:00

> From: Hamish Mackenzie [mailto:hamish_at_[hidden]]
> 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.
> 
> See description SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE in
various
> openssl functions (SSL_connection, SSL_read SSL_write, ...)

I've encountered this myself in trying to insert SSL into a lib like the
proposed one. Portable error handling is definitely not simple - we
(kind of) gave up on a general solution. However, we also tried to hide
the SSL peculiarities from the user as best we could. We return a "would
block" result for both of the SSL_WANT_ results. This didn't break much
code because we were already pessimistic enough to think that select (or
a driver) might have been less than accurate in reporting that it was
ready.

> 
> Another thing worth noting is that it also requires that you use the
> same buffer when you repeat the write (after SSL_ERROR_WANT_???? was
> returned)
> 

Yes - though the real requirement is that you try to send the same
content (you can append extra, you just can't change stuff that was in
the original buffer). There is an OpenSSL compile option to remove the
check for the same buffer address being re-used. We couldn't think of a
reasonable way of enforcing the same content rule without proscribing
too much about how I/O was handled in the user code, so we just
documented this requirement. In practice, it hasn't (so far) needed
explicit coding/changes to meet the requirement.

> > [snip]
> > > Another tricky issue with openssl is the ability to have different
> read
> > > and write file descriptors for an ssl connection.
> >
> > Is this effectively using one socket for communication in each
> direction?
> > ie non-duplex operation ?
> 
> That is my understanding (I haven't had a need for this myself).
> See SSL_set_fd, SSL_set_rfd and SSL_set_wfd.
> 

It is important to remember that SSL/TLS do not assume TCP or any
particular transport. If someone wants to run SSL over a pair of simplex
connections they can. The most obvious case I can think of is running it
over pipes. I haven't needed this (yet). I would think a motivated
individual could make an interesting socket class that had an
interesting underlying socket/fd  type (a pair of fds)? 

Regards
Darryl Green.