David Schwartz wrote:
Not to beat a dead horse, but I forgot to mention that the application
does work "properly" when performing the same operations on non-SSL
connections. In other-words if I use telnet to connect to the server on
the non-SSL port and type nothing in the console and then have a
D]
[mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz
Sent: 20 July 2007 09:18
To: openssl-users@openssl.org
Subject: RE: How to prevent SSL from blocking from Network interruption
> Having only done minimal socket programming, I'm in a bit of a steep
> learning curve right now. Oth
> Having only done minimal socket programming, I'm in a bit of a steep
> learning curve right now. Other then understanding what a blocking and
> non-blocking operation is, I don't fully understand the ramifications of
> switching to non-blocking I/O. Compounding this issue is the third party
> co
> Not to beat a dead horse, but I forgot to mention that the application
> does work "properly" when performing the same operations on non-SSL
> connections. In other-words if I use telnet to connect to the server on
> the non-SSL port and type nothing in the console and then have a second
> clien
On Jul 19, 2007, at 9:45 PM, Jim Marshall wrote:
Jim Marshall wrote:
David Schwartz wrote:
OpenSSL tries to make SSL connections act like regular TCP
connections. This
is exactly what TCP does. So your application would have this
exact same
problem with or without OpenSSL. As such, how can
Jim Marshall wrote:
David Schwartz wrote:
OpenSSL tries to make SSL connections act like regular TCP
connections. This
is exactly what TCP does. So your application would have this exact same
problem with or without OpenSSL. As such, how can you blame it on
OpenSSL?
Not to beat a dead horse,
David Schwartz wrote:
We are working on a threaded solution but right now we are using some
third-party code (Webs 2.18) which is single threaded.
That's fine, but if you using blocking calls in a single-threaded
application, you can really only handle one client at a time.
I know :( Which is w
> We are working on a threaded solution but right now we are using some
> third-party code (Webs 2.18) which is single threaded.
That's fine, but if you using blocking calls in a single-threaded
application, you can really only handle one client at a time.
> I'm also not sure I understand your a
Date: Thu, 19 Jul 2007 16:09:59 -0400
From: Jim Marshall <[EMAIL PROTECTED]>
To: openssl-users@openssl.org
Reply-To: openssl-users@openssl.org
Subject: Re: How to prevent SSL from blocking from Network interruption
Victor Duchovni wrote:
On Thu, Jul 19, 2007 at 03:54:55PM -0400, Jim Ma
Victor Duchovni wrote:
On Thu, Jul 19, 2007 at 03:54:55PM -0400, Jim Marshall wrote:
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
Once a TCP session is in the Established state, it stays that way
until a FIN or RST is received from the opposite host, or if a
packet times out. This is the purpose of keepalive. However,
the default time for keepalive is a system wide setting and is
usually very long, and may not be appropriat
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
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
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 min
14 matches
Mail list logo
