------=_Part_1581_20490795.1206038986560
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi David,

On Thu, Mar 20, 2008 at 12:38 PM, David Schwartz
wrote:

>
> > Hi David,

>
> > My code looks like this:

>
> 1 while(1)
> 2 {
> 3 r = SSL_accept(m_ssl);
> 4 if (r > 0)
> 5 {
> 6 break;
> 7 }
> 8 r = ssl_retry(r);
> 9 if ( r <= 0)
> 10 {
> 11 break;
> 12 }
> 13 }
>
> Well, that's obviously badly broken. It's probably not precisely your
> issue,
> but it's related. Since the socket is non blocking, there is no place for
> this code to block waiting for the connection!




Well, that is not true and I am sorry I did not give you the full code as it
is quite complicated but the snipet you see above is called after a new
connection is already accepted. So I have an outer loop that does a select
and once a new connection is detected and accepted without errors, I go
ahead establishing the ssl part... Something like:


ready_sockets = ::select(m_max_socket + 1, rfds, 0, 0,&tv);
if (ready_sockets > 0)
{
if (FD_ISSET(s->get_sock(),p->get_rfds()))
{
new_s->set_non_blocking(true);
if (s->accept(new_s))
{
call the code above which will call SSL_accept
}
else
{
/*error handling*/
}


So when the SSL_accept is called I already know that accept succeed and no
EMFILE or ENFILE is generated.


I am setting the socket as non blocking by simply calling:

if (fcntl(m_sock_fd, F_SETFL, O_NONBLOCK) == -1)
{
return false;
}

I am confused when you say if my BIO is non-blocking too. I thought that it
is non blocking since the underlying socket is non blocking. Is this a wrong
assumption? if so how can I make the BIO non blocking [BIO_set_nbio?]

Thank you for you help.


>
> > The issue is not that it is going into an infinite while loop.

>
> That's just pure luck.
>
> > The issue is that SSL_accept on line 3 never returns!.
> > My socket is a non blocking one so as far as I know
> > SSL_accept should return.

>
> How did you make it non blocking exactly? And is the BIO non-blocking too?
>
> > A backtrace shows that when this happen the server gets stuck in:

>
> > SSL_accept
> > after calling SSL_accept.

>
> Sounds like you're lucky. The BIO is actually blocking and that's saving
> your code from looping. At least you're not burning the CPU.
>
> What is your design intention if 'accept' returns EMFILE or ENFILE? If
> your
> answer is "I have no idea" or "I never really thought about it", then it's
> no surprise your code mishandles this case.
>
> DS
>
>
> __________________________________________________ ____________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager majordomo@openssl.org
>


------=_Part_1581_20490795.1206038986560
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi David,

On Thu, Mar 20, 2008 at 12:38 PM, David Schwartz <davids@webmaster.com> wrote:



> Hi David,



> My code looks like this:



1      while(1)

2      {

3                r = SSL_accept(m_ssl);

4                if (r > 0)

5                {

6                     break;

7                }

8                r = ssl_retry(r);

9                if ( r <= 0)

10             {

11                  break;

12            }

13    }



Well, that's obviously badly broken. It's probably not precisely your issue,

but it's related. Since the socket is non blocking, there is no place for

this code to block waiting for the connection!


Well, that is not true and I am sorry I did not give you the full code as it is quite complicated but the snipet you see above is called after  a new  connection is already accepted. So I have an outer loop that does a select and once a new connection is detected and accepted without errors, I go ahead establishing the ssl part... Something like:



      ready_sockets = ::select(m_max_socket + 1, rfds, 0, 0,&tv);
      if (ready_sockets > 0)
      {
         if (FD_ISSET(s->get_sock(),p->get_rfds()))
         {
            new_s->set_non_blocking(true);

            if (s->accept(new_s))
            {
                       call the code above which will call SSL_accept
            }
            else
            {
             /*error handling*/
            }



So when the SSL_accept is called I already know that accept succeed and no EMFILE or ENFILE is generated.


I am setting the socket as non blocking by simply calling:

                if (fcntl(m_sock_fd, F_SETFL, O_NONBLOCK) == -1)

                {               
                        return false;
                }

I am confused when you say if my BIO is non-blocking too. I thought that it is non blocking since the underlying socket is non blocking. Is this a wrong assumption? if so how can I make the BIO non blocking [BIO_set_nbio?]


Thank you for you help.





> The issue is not that it is going into an infinite while loop.



That's just pure luck.



> The issue is that SSL_accept on line 3 never returns!.

> My socket is a non blocking one so as far as I know

> SSL_accept should return.



How did you make it non blocking exactly? And is the BIO non-blocking too?



> A backtrace shows that when this happen the server gets stuck in:



> SSL_accept

> after calling SSL_accept.



Sounds like you're lucky. The BIO is actually blocking and that's saving

your code from looping. At least you're not burning the CPU.



What is your design intention if 'accept' returns EMFILE or ENFILE? If your

answer is "I have no idea" or "I never really thought about it", then it's

no surprise your code mishandles this case.



DS





__________________________________________________ ____________________

OpenSSL Project                                 http://www.openssl.org

User Support Mailing List                    penssl-users@openssl.org">openssl-users@openssl.org

Automated List Manager                           majordomo@openssl.org




------=_Part_1581_20490795.1206038986560--
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majordomo@openssl.org