Documentation on using the SSL library with non-blocking I/O.

openssl · Nov 17, 2000 · b1d6e3f · b1d6e3f
1 parent db70a3f
commit b1d6e3f
Show file tree

Hide file tree

Showing 2 changed files with 16 additions and 1 deletion.
diff --git a/FAQ b/FAQ
@@ -6,6 +6,7 @@ OpenSSL  -  Frequently Asked Questions
 * How can I contact the OpenSSL developers?
 * Do I need patent licenses to use OpenSSL?
 * Is OpenSSL thread-safe?
+* Can I use OpenSSL's SSL library with non-blocking I/O?
 * Why do I get a "PRNG not seeded" error message?
 * Why does the linker complain about undefined symbols?
 * Where can I get a compiled version of OpenSSL?
@@ -103,6 +104,20 @@ Multi-threaded applications must provide two callback functions to
 OpenSSL.  This is described in the threads(3) manpage.
 
 
+* Can I use OpenSSL's SSL library with non-blocking I/O?
+
+Yes; make sure to read the SSL_get_error(3) manual page!
+
+A pitfall to avoid: Don't assume that SSL_read() will just read from
+the underlying transport or that SSL_write() will just write to it --
+it is also possible that SSL_write() cannot do any useful work until
+there is data to read, or that SSL_read() cannot do anything until it
+is possible to send data.  One reason for this is that the peer may
+request a new TLS/SSL handshake at any time during the protocol,
+requiring a bi-directional message exchange; both SSL_read() and
+SSL_write() will try to continue any pending handshake.
+
+
 * Why do I get a "PRNG not seeded" error message?
 
 Cryptographic software needs a source of unpredictable data to work

diff --git a/doc/ssl/SSL_get_error.pod b/doc/ssl/SSL_get_error.pod
@@ -65,7 +65,7 @@ TLS/SSL I/O function should be retried.
 Caveat: Any TLS/SSL I/O function can lead to either of
 B<SSL_ERROR_WANT_READ> and B<SSL_ERROR_WANT_WRITE>.  In particular,
 SSL_read() may want to write data and SSL_write() may want to read
-data.  This is because TLS/SSL handshakes may occur at any time
+data.  This is mainly because TLS/SSL handshakes may occur at any time
 during the protocol (initiated by either the client or the server);
 SSL_read() and SSL_write() will handle any pending handshakes.