+ struct ofpbuf *rxbuf;
+ struct ofpbuf *txbuf;
+ struct poll_waiter *tx_waiter;
+
+ /* rx_want and tx_want record the result of the last call to SSL_read()
+ * and SSL_write(), respectively:
+ *
+ * - If the call reported that data needed to be read from the file
+ * descriptor, the corresponding member is set to SSL_READING.
+ *
+ * - If the call reported that data needed to be written to the file
+ * descriptor, the corresponding member is set to SSL_WRITING.
+ *
+ * - Otherwise, the member is set to SSL_NOTHING, indicating that the
+ * call completed successfully (or with an error) and that there is no
+ * need to block.
+ *
+ * These are needed because there is no way to ask OpenSSL what a data read
+ * or write would require without giving it a buffer to receive into or
+ * data to send, respectively. (Note that the SSL_want() status is
+ * overwritten by each SSL_read() or SSL_write() call, so we can't rely on
+ * its value.)
+ *
+ * A single call to SSL_read() or SSL_write() can perform both reading
+ * and writing and thus invalidate not one of these values but actually
+ * both. Consider this situation, for example:
+ *
+ * - SSL_write() blocks on a read, so tx_want gets SSL_READING.
+ *
+ * - SSL_read() laters succeeds reading from 'fd' and clears out the
+ * whole receive buffer, so rx_want gets SSL_READING.
+ *
+ * - Client calls vconn_wait(WAIT_RECV) and vconn_wait(WAIT_SEND) and
+ * blocks.
+ *
+ * - Now we're stuck blocking until the peer sends us data, even though
+ * SSL_write() could now succeed, which could easily be a deadlock
+ * condition.
+ *
+ * On the other hand, we can't reset both tx_want and rx_want on every call
+ * to SSL_read() or SSL_write(), because that would produce livelock,
+ * e.g. in this situation:
+ *
+ * - SSL_write() blocks, so tx_want gets SSL_READING or SSL_WRITING.
+ *
+ * - SSL_read() blocks, so rx_want gets SSL_READING or SSL_WRITING,
+ * but tx_want gets reset to SSL_NOTHING.
+ *
+ * - Client calls vconn_wait(WAIT_RECV) and vconn_wait(WAIT_SEND) and
+ * blocks.
+ *
+ * - Client wakes up immediately since SSL_NOTHING in tx_want indicates
+ * that no blocking is necessary.
+ *
+ * The solution we adopt here is to set tx_want to SSL_NOTHING after
+ * calling SSL_read() only if the SSL state of the connection changed,
+ * which indicates that an SSL-level renegotiation made some progress, and
+ * similarly for rx_want and SSL_write(). This prevents both the
+ * deadlock and livelock situations above.
+ */
+ int rx_want, tx_want;