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 is a
mistake. (What is 'Errno' anyway?)
r = SSL_connect(m_ssl);
if (r > 0)
{
break;
}
r = ssl_retry(r);
if ( r <= 0)
{
break;
}
t = time(NULL) - time0;
}
Err, what? Is an ssl_retry return of zero supposed to indicate a fatal
error? The code in ssl_retry doesn't seem to follow this rule. (For
example, consider if 'select' returns zero and errno is zero. That would
indicate a timeout, not a fatal error.)
int time0 = time(NULL);
timeout=10 seconds;
while (t<timeout)
{
r = SSL_accept(m_ssl);
if (r > 0)
{
break;
}
r = ssl_retry(r);
if ( r <= 0)
{
break;
}
t = time(NULL) - time0;
}
if (t>=timeout)
There no code to initially set 't'.
Also, an overall comment: Maybe it's just my taste, but your code seems
to have a 'worst of both worlds' quality to it. It uses non-blocking
sockets, but then finds clever ways to make the non-blocking operations
act like blocking ones.
Is the server multithreaded? If so, I could see this as mere laziness
(or, efficient use of coding resources to be more charitable) rather
than actual poor design.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
