> From: Hamish Mackenzie [mailto:[EMAIL PROTECTED]] > 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
