|
Boost : |
From: Hamish Mackenzie (hamish_at_[hidden])
Date: 2002-11-25 12:17:41
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.
See description SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE in various
openssl functions (SSL_connection, SSL_read SSL_write, ...)
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)
> [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.
> > In my opinion socket_exception should derive from std::exception.
> definitely
>
> > However what() should return nothing more than "socket error". The
> > reason for this is that any more information like "dns lookup error for
> > host xyz.abc.com" could reveal sensitive information about ones network.
> Not sure that his is the right place to be hiding information
Yes maybe it is a bit paranoid. If we use an error policy though there
could be one for the paranoid policy which provides very little info and
one for use in testing that gives a detailed error message.
> > I like the idea of having an error policy
> So do I. What is the reasoning for passing socket_function and args ?
> I have aded a preliminary ErrorPolicy, without the arguments to handle_error.
They are there to allow detailed exceptions and error logging. In fact
can we make socket_function a compile time argument.
Here is an example...
template< socket_function Function >
class detailed_socket_exception : public socket_exception {};
template<>
class detailed_socket_exception< send > : public socket_exception
{
public:
const char * what() const throw()
{
return "socket error in send";
}
};
class detailed_error_policy
{
public:
template< socket_function f, typename TupleArgs >
int handle_error( int err, TupleArgs args )
{
throw detailed_socket_exception< f >();
}
BOOST_STATIC_CONSTANT( bool, nothrow = false );
};
-- 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