This may be a stretch, but did you confirm the socket is within the
range of sockets your platform allows you to 'select' on? For example,
Linux by default doesn't permit you to 'select' on socket numbers 1,025
and up, though you can have more than 1,024 file descriptors in use
without a pro
On Wed, Nov 3, 2010 at 9:12 AM, David Schwartz wrote:
> On 11/2/2010 6:25 PM, Md Lazreg wrote:
>
>> r=select(m_sock_fd + 1, &fds, 0, 0, ptv);
>> if (r <= 0 && (Errno == EAGAIN || Errno == EINTR))/*if we timed
>> out with EAGAIN try again*/
>> {
>> r = 1;
>>
On 11/2/2010 6:25 PM, Md Lazreg wrote:
r=select(m_sock_fd + 1, &fds, 0, 0, ptv);
if (r <= 0 && (Errno == EAGAIN || Errno == EINTR))/*if we timed
out with EAGAIN try again*/
{
r = 1;
}
This code is broken. If 'select' returns zero, checking errno
> From: owner-openssl-us...@openssl.org On Behalf Of Sam Jantz
> Sent: Tuesday, 07 September, 2010 17:29
> Where are SSL_accept, and SSL_connect defined? Specifically
> for TLSv1, and SSLv3 connections. I found the definition
> in ssl_lib.c but then that calls s->meth
Original message
>Date: Fri, 30 Mar 2007 12:01:54 -0700
>From: "David Schwartz" <[EMAIL PROTECTED]>
>Subject: RE: SSL_connect and SSL_accept
>To:
>
>
>> So what you are saying is the scenario we have been discussing so far is
>> possibl
> So what you are saying is the scenario we have been discussing so far is
> possible ONLY in case of memory allocation issues NOT OTHERWISE.
> I guess I will have a look at the SSL_connect code before I just
> trust this
> :-)
I would still recommend coding to handle this case. Perhaps the next
I have spent quite some time with SSL_connect, and apart from tcp level
socket failures (transient/fatal) and SSL Handshake failures it cannot
return error, so ur case is NOT POSSIBLE unless the HOST has run out of
memory wherein Openssl_malloc itself fails. So I dont suppose you need to
worry ab
ure (timeout),
it would report failure to the client
~ Urjit
- Original Message -
From: "Gayathri Sundar" <[EMAIL PROTECTED]>
To:
Sent: Friday, March 30, 2007 9:25 AM
Subject: Re: SSL_connect and SSL_accept
I am quite clear with your problem and am not confused. The only point I
ha
- Original Message -
From: "Gayathri Sundar" <[EMAIL PROTECTED]>
To:
Sent: Thursday, March 29, 2007 4:07 PM
Subject: Re: SSL_connect and SSL_accept
Urjit.,
1st of all theoritically your are 100% correct, after all SSL runs in the
SESSION layer, but it depends on the underlying tran
Sundar" <[EMAIL PROTECTED]>
To:
Sent: Thursday, March 29, 2007 4:07 PM
Subject: Re: SSL_connect and SSL_accept
Urjit.,
1st of all theoritically your are 100% correct, after all SSL runs in the
SESSION layer, but it depends on the underlying transport connection, and
if that has pr
: "Gayathri Sundar" <[EMAIL PROTECTED]>
To:
Sent: Thursday, March 29, 2007 4:07 PM
Subject: Re: SSL_connect and SSL_accept
Urjit.,
1st of all theoritically your are 100% correct, after all SSL runs in the
SESSION layer, but it depends on the underlying transport connection,
Urjit Gokhale wrote:
> I believe you are confusing tcp/ip connection establishment and SSL session
> establishment.
>
... and you should also remember that a reliable transport is a
prerequisite for tls.
> The problem may occur when:
> 1) Server is waiting for first SSL handshake packet in SSL_a
with respect to the current thread. So I will
send a new post for that.
Thank you everyone for responding.
~ Urjit
- Original Message -
From: "Gayathri Sundar" <[EMAIL PROTECTED]>
To:
Sent: Thursday, March 29, 2007 1:02 PM
Subject: RE: SSL_connect and SSL_accept
Yes, I agr
send a
new post for that.
Thank you everyone for responding.
~ Urjit
- Original Message -
From: "Gayathri Sundar" <[EMAIL PROTECTED]>
To:
Sent: Thursday, March 29, 2007 1:02 PM
Subject: RE: SSL_connect and SSL_accept
Yes, I agree with you, but then why would the CLIENT g
Hi,
> > I am unable to think of a scenerio why ur case is possible
> unless some
> > serious network congestion has developed and pkts were
> lost..i dont see
> > how..but the experts might able to give u a better idea.
>
> You get a SYN, send a SYN ACK, other side sends an ACK, then the other
Yes, I agree with you, but then why would the CLIENT get an ERROR?
>2) The client calls SSL_connect(). The underlying socket is in blocking
>mode
>3) SSL_connect() returns error.
>4) The server does not notice this, and continues to wait in SSL_accept().
if SSL_connect indeed has returned with ER
> I am unable to think of a scenerio why ur case is possible unless some
> serious network congestion has developed and pkts were lost..i dont see
> how..but the experts might able to give u a better idea.
You get a SYN, send a SYN ACK, other side sends an ACK, then the other
side's Internet conn
>I am wondering if the following scenario possible:
>1) The server calls SSL_accept(). The underlying socket is in blocking mode
>2) The client calls SSL_connect(). The underlying socket is in blocking
>mode
>3) SSL_connect() returns error.
>4) The server does not notice this, and continues to wait
> > If the scenario mentioned above is possible, then the server
> > will be blocked in the SSL_accept() (until the underlying tcp
> > connection is broken) and hence wont be able to service other
> > clients' connection requests
>
> This is the Toyota Principle, "you asked for it, you got it." If
> If the scenario mentioned above is possible, then the server
> will be blocked in the SSL_accept() (until the underlying tcp
> connection is broken) and hence wont be able to service other
> clients' connection requests
This is the Toyota Principle, "you asked for it, you got it." If you don't
20 matches
Mail list logo
