The scenario you are describing is simply impossible. > It is possible (even very likely) that the upstream plaintext buffer in > the "stunnel-like half-duplex-handling proxy application" happens to be > empty, but that the local plaintext source file descriptor is still open.
True. > The half-duplex-handling proxy application that you and I decided to > build says: "Fine, I'll use poll() to sleep until the plaintext source > file descriptor delivers some data that we can then SSL_write()". There is no way this can cause a problem. It's just impossible. > So, the proxy event loop that we built so nicely registers the local > plaintext source file descriptor for POLLIN, and it registers the > SSL-TCP file descriptor for POLLIN/POLLOUT guided by > SSL_want_read()/_write(), like it always does. And then it does poll(). Great. That's perfect. > At that point we get stung because SSL_want_read() erroneously returned > 'true' and we therefore registered the SSL-TCP file descriptor for > POLLIN, even though OpenSSL (and only OpenSSL) knows that the SSL-TCP > file descriptor has already returned read()==0. This is insane. Imagine if SSL_want_read and SSL_want_write both returned false. Then you wouldn't ever notice that the socket had been closed, you could wait for new inbound data forever, and your proxy would stall. If the socket is readable, you can make forward progress. SSL_want_read *correctly* returns true to indicate this. When you detect this and call SSL_read, it *correctly* reports to you that the connection is closed. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
