On Fri, Feb 07, 2003 at 12:15:31PM -0800, David Schwartz wrote:
> On Fri, 7 Feb 2003 20:42:50 +0100, Jasper Spit wrote:
>> My point was to make clear that your statement that 'it is almost always
>> an error to use select() with non blocking sockets' is simply not true.
>> I think that might be re
On Fri, 7 Feb 2003 22:27:51 +0200 (FLE Standard Time), Arne Ansper
wrote:
>I'm sorry. It seems to me that you made a small mistake in your
>original
>post or your definition of "non-blocking socket" is different than
>other
>peoples.
>
>You said:
>
>"It is almost always an error to use 'select' wi
> >>It is almost always an error to use 'select' with non-blocking
> >>sockets.
>
> >Er, why do you think so? It's pretty standard to use 'select' (or
> >'poll') with non-blocking sockets to avoid busy waiting.
>
> You either can block or you can't. If you can block, why are you
> call
On Fri, 7 Feb 2003 20:42:50 +0100, Jasper Spit wrote:
>My point was to make clear that your statement that 'it is almost
>always
>an error to use select() with non blocking sockets' is simply not
>true.
>I think that might be relevant to other openssl users.
I stand by my point until and
On Fri, 7 Feb 2003 14:44:58 +0100, Bodo Moeller wrote:
>>It is almost always an error to use 'select' with non-blocking
>>sockets.
>Er, why do you think so? It's pretty standard to use 'select' (or
>'poll') with non-blocking sockets to avoid busy waiting.
You either can block or you
PROTECTED]] Namens David Schwartz
Verzonden: vrijdag 7 februari 2003 0:52
Aan: [EMAIL PROTECTED]
Onderwerp: RE: SSL_accept hang
On Thu, 6 Feb 2003 20:34:23 +0100, Jasper Spit wrote:
>I can confirm that. select() works fine for both blocking and
>non-blocking i/o, even on Windows :)
On 04 Feb 2003 07:12:16 -0800, Eric Rescorla wrote:
>Are you saying that setsockopt(SO_RCVTIMEO) is broken?
Yes, I am. Check out SuSv3:
SO_RCVTIMEO
Sets the timeout value that specifies the maximum amount of time an
input function waits until it completes. ... Note that not all
implement
Can you please elaborate on the algorithm you are using to accept
connections? The SSL_accept() does not take a server socket (the
socket on which the accept() call is performed.) Therefore, I do not
know why the SSL_accept() should block accept() calls unless you are
calling them in sequence
: SSL_accept hang
This doesn't really solve the problem of timeouts, as
you will now have a dead thread lying around.
Tim
--- Jasper Spit <[EMAIL PROTECTED]> wrote:
> Don't know if this is appropriate for you, but if
> you're using a
> multithreaded app, make sure the
This doesn't really solve the problem of timeouts, as
you will now have a dead thread lying around.
Tim
--- Jasper Spit <[EMAIL PROTECTED]> wrote:
> Don't know if this is appropriate for you, but if
> you're using a
> multithreaded app, make sure the SSL_accept call
> takes place in a
> seperate t
Title: Bericht
Don't
know if this is appropriate for you, but if you're using a multithreaded app,
make sure the SSL_accept call takes place in a seperate thread (dedicated for
that client). That way if the connecting party never initiates or
completes a handshake, your application will stil
As long as you are on a Windows system that implements WinSock2 all you
need to do is specify
int timeout = 15;
setsockopt(socket, SOL_SOCKET, SO_RCVTIMEO, &timeout,
sizeof(int));
This will result in the following behaviors as described in
http://msdn.microsoft.com/library/default.asp
Tim Regovich <[EMAIL PROTECTED]> writes:
> One point that I thought was implicit in my comment
> when I started was that the timeout approach using
> some sort of alarm around a call to say SSL_accept, is
> that you cannot use the TCP timeouts, because
> SSL_accept wraps a whole serious of TCP tran
What a lively discussion!
One point that I thought was implicit in my comment
when I started was that the timeout approach using
some sort of alarm around a call to say SSL_accept, is
that you cannot use the TCP timeouts, because
SSL_accept wraps a whole serious of TCP transactions.
My assertion
David Schwartz <[EMAIL PROTECTED]> writes:
> On 03 Feb 2003 22:00:08 -0800, Eric Rescorla wrote:
>
> >David Schwartz <[EMAIL PROTECTED]> writes:
>
> >>You nearly always need non-blocking, even if it's just for
> >>timeouts.
>
> >Depends. If you're just setting some global timeout, you
> >can us
On 03 Feb 2003 22:00:08 -0800, Eric Rescorla wrote:
>David Schwartz <[EMAIL PROTECTED]> writes:
>>You nearly always need non-blocking, even if it's just for
>>timeouts.
>Depends. If you're just setting some global timeout, you
>can use blocking I/O perfectly well.
There will almost alwa
David Schwartz <[EMAIL PROTECTED]> writes:
> On 03 Feb 2003 19:01:53 -0800, Eric Rescorla wrote:
> >Tim Regovich <[EMAIL PROTECTED]> writes:
>
> >>*always* operate in non blocking mode. The code may
> >>be slightly more complex but will *always* work
> >>better.
>
> >I don't agree with this. Ge
On 03 Feb 2003 19:01:53 -0800, Eric Rescorla wrote:
>Tim Regovich <[EMAIL PROTECTED]> writes:
>>*always* operate in non blocking mode. The code may
>>be slightly more complex but will *always* work
>>better.
>I don't agree with this. Getting non-blocking code correct
>with OpenSSL is quite trick
Tim Regovich <[EMAIL PROTECTED]> writes:
> *always* operate in non blocking mode. The code may
> be slightly more complex but will *always* work
> better.
I don't agree with this. Getting non-blocking code correct
with OpenSSL is quite tricky. If you don't need non-blocking,
there's no reason to d
kard
>
> -Original Message-
> From: Eric Rescorla [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 03, 2003 11:04 AM
> To: [EMAIL PROTECTED]
> Subject: Re: SSL_accept hang
>
>
> "Skip Rhudy" <[EMAIL PROTECTED]> writes:
> > We use OpenSSL
corla [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 03, 2003 11:04 AM
To: [EMAIL PROTECTED]
Subject: Re: SSL_accept hang
"Skip Rhudy" <[EMAIL PROTECTED]> writes:
> We use OpenSSL on in a Win2k environment. The latest code we have is
> 0.9.6h.
>
>
>
> If SS
21 matches
Mail list logo
