Hi Jim - thanks for the reply. See comments in-line
Jim Fox wrote:
I have a single threaded test application (Red Hat Linux release 9 -
Shrike), OpenSSL 0.9.8. I found that it's possible to permanently
hang a thread receiving SSL calls if a network interruption occurs
during an established connection.
This is the way TCP works. There's a couple of minute timeout
built into it. You can circumvent this behavior by setting
your ssl sockets to non-blocking, but if you can switch to
threaded processing that'd be the easier way to go.
We are working on a threaded solution but right now we are using some
third-party code (Webs 2.18) which is single threaded.
I'm also not sure I understand your answer "This is the way TCP works".
When we disconnect the network cable the connection never times out (we
left it for at least 30 minutes).
Let me give you (and others) a more concrete example. I took the
wserver2 sample from http://www.rtfm.com/openssl-examples/ and built on
FC 6. I started the server like so
./wserver2 -n
Then from another machine I telnet to the wserver2 machine
telnet <ip address> 4433
I just let telnet connect and don't type anything. The connection
remains 'ESTABLISHED'. and no other client connections will work (e.g.
wclient2). This is basically the behavior we are seeing with our
application. A client connects and never sends any data, so it remains
connected, hence blocking any other client from communicating.
This seems to me (in my very novice opinion) to be an issue with
openSSL, in the sense that if it doesn't get a handshake (or some other
data) on the connection it should close the connection after a period of
time.
Thanks
Jim
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
