On Thu, Jul 19, 2007 at 03:54:55PM -0400, Jim Marshall wrote:
> 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).
TCP only disconnects quickly when a writer re-tranmits unacked data.
TCP never[1] disconnects when a reader waits for more data, this requires
an application timeout.
--
Viktor.
[1] When you enable TCP keep-alives, the reader sends periodic zero
length probes and so becomes a writer, thereby detecting a broken
connection. The default keepalive timer from BSD 4.2 days is 2 hours,
but this is nowdays tunable using sysctl, ndd, ...
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
