I have read in this SO question that OpenSSL socket communication can be only half duplex in a single thread.

Assuming what I have read is true, I am wondering if I can apply philosopher's dining problem to send SSL_write() and receive SSL_read() on a non-blocking socket in a single thread that communicates with a OpenSSL TCP Server. Both server and client are non-blocking.

Would that be a good model? Or should I always set priority to read SSL_read()? What would be the best approach to code?

I am using C++ to code this single threaded non-blocking socket model (without BOOST or other libraries).


1 Answer 1


From the comments I see that your "half-duplex" refers to the fact, that you should not operate on the same SSL object from different threads at the same time (or use explicit locking) and thus cannot use SSL_read and SSL_write at the same time from different threads.

While most protocols are request/response and thus don't need parallel read and write the usual way to reach what you want is with non-blocking I/O and select. This works similar to non-blocking I/O with normal sockets. There are two major differences:

  • There might be SSL handshakes inside SSL_read and SSL_write, so a SSL_read might need to write data and SSL_write might need to read data. So you need to check for the ERROR_SSL_WANT_READ and ERROR_SSL_WANT_WRITE conditions. Same with SSL_connect and SSL_accept.
  • SSL_read returns only the amount of data you ask for, but there might be more data in the SSL frame. In this case the data are buffered internally inside the SSL object and you will not get from a call to select that there are more data (because they've already read from the socket). You need to check for this case with SSL_pending, or make sure that you always try to read the maximum amount of data which fits into an SSL frame (16k).

And for your dining philosophers: You have this kind of problem only with threads. With single-threaded you don't need locking and thus have no locking problems (which often makes the code faster too because of no lock contention).

  • Thanks for answering this. I actually do error checking for want_read and want_write and return code. I was not sure why flags were used in the code in 2nd link even though it is single thread. They make sure the SSL object read and write operations do not overlap. Jul 7, 2014 at 11:22
  • I'm not sure what "flags" you mean. In case you mean ERROR_SSL_WANT_*: if a (re)negotiation occurs a SSL_read might need the underlying socket to write and a SSL_write might need it to read. So you need to check the flags even if single-threaded. Jul 7, 2014 at 14:06
  • Sorry I was not clear before. I was actually referring to the flags "write_blocked_on_read" and "read_blocked_on_write" "read_blocked" in code on listing 8 on linuxjournal.com/node/5487/print .If you notice they are interlaced in that code. I was trying to understand the reasoning behind the same. Jul 7, 2014 at 16:10
  • 1
    This looks like a way to call SSL_read only if there the original intention was to read and not to write but it blocked on read etc - I don't think the code is very intuitive and I would not do it this way but it is probably working. Jul 7, 2014 at 16:21
  • Actually that whole flags thing got me thinking about dining philosophers problem and half duplex used of SSL object. Jul 7, 2014 at 16:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.