> From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > us...@openssl.org] On Behalf Of Tilman Sauerbeck > Sent: Friday, 09 May, 2014 18:57 > > Michael Wojcik [2014-05-09 21:12]: > > > > From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > > > us...@openssl.org] On Behalf Of Tilman Sauerbeck > > > Sent: Thursday, 08 May, 2014 12:26 > > > > > > my program is an SSL client which is reading large amounts of data > > > without sending data itself (after the initial handshake). > > > ... > > > Another attempt was to use select() to check if the socket is readable > > > just before calling SSL_read(), like so: > > > > That's not useful in your case. When you're receiving on a TCP connection > and not sending, and the connection is closed, the socket will be flagged as > readable. With select() you can't distinguish between a connection that has > data available and a connection that has received a TCP FIN or RST. > > Yes, and I wanted to only ask OpenSSL to read from the socket if it was > readable. I wouldn't care if that read() returned 0.
OK. I misinterpreted your original note. I still don't know what exactly a "dropped connection" constitutes in your case, though, or how the TCP/IP stack is handling it. That makes quite a difference. If the stack treats it as transient, the socket won't be readable. > > I suspect it doesn't work because select is returning non-zero, because the > socket is readable. > > If the socket was readable, the following call to SSL_read() wouldn't > block though. However with that snippet, I'm still seeing hanging > read() calls. I'd have to debug through the SSL_read code to comment. I've seen it do some questionable things (in OpenSSL 0.9.8, which was the most recent version where I had cause to debug SSL_read), but the logic is convoluted enough that I didn't take the time to confirm the behavior was actually wrong. > > Only that usual practice for an application that wants to be able to abort > a TCP receive operation is to use non-blocking sockets. SO_RCVTIMEO was > created when threading became commonly available on UNIX platforms and > blocking network I/O became a more usable approach for complex applications. > Consequently, most people who want more control over the behavior of a > passive TCP endpoint still use nonblocking sockets. > > I guess I thought SO_RCVTIMEO was widespread enough for OpenSSL to > handle it or mention it in the documentation... SO_RCVTIMEO is standard, as I noted, but SUSv3 doesn't require that it actually work. I don't know how widely it's implemented in contemporary TCP/IP stacks, or whether you have to support any old stacks that don't support it. What I meant above was more along the lines of "because most people acquired the habit of using non-blocking sockets, probably there aren't many who have tried to use SO_RCVTIMEO with OpenSSL". I don't think there's anything wrong with SO_RCVTIMEO (except for processes handling a lot of conversations, where non-blocking sockets and multiplexed I/O offer less overhead and more capacity than a bunch of threads blocking in network I/O). It simply may be something that the BIO code doesn't handle very well. As for the OpenSSL documentation ... let's just say there are a lot of things it doesn't mention. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
