Since you use a nonblocking connect, you're essentially telling the
software you want instant return. Which is what you get.
Given that a TCP connection takes a little time (three network travels
at least), that's definitely more time than you wish to wait given
your nonblocking intent, so the IP stack properly and correctly tells
you it'll take some time before you get the final result -->
wouldblock.
The next bit is where I'm a bit rusty (read as: the peculiarities of
WinSock have eroded in my brain), but a glance at the code shows
you're only select()ing for writing and IIRC a finalized non-blocking
connect is equivalent to a 'ready-for-READING' select signal - for
which you are not listening in your select as that argument is NULL.
Hence my advise to also pass your handle in a separate fdset to
select(read), i.e
status = select(m_sock_fd+1, &myreadset, &mywriteset,
NULL, &tv);
(so you can tell upon return which one fired)
and lastly there's the ever-there mind-you nitpick that nonblocking
I/O is well served with a statemachine around it, i.e. a loop, which
tracks the current state of your connections/activity and acts upon
that - it's the long way of saying that a connection may take longer
than 20 seconds to establish, so an if-chain and a long wait isn't the
end-all there, but this nitpick is not your problem. Yet. And the code
structure is not enough to prove there's no statemachine already there
in your code; the current code layout is a (very) weak hint, 's all.
Anyway, a tip: this is generic TCP/IP socket programming we're talking
about here and do yourself a favor and get a hold of the books by W
Richard Stevens (R.I.P.). It's what I grew up with and those books of
his have been among the very few which have never let me down in the
hour of need. They're still 100% applicable and for IPv6 specifics,
there's little enough change that the internet and manpages suffice
for that. They are not WinSock specific, but for that one's
peculiarities (such as the WSASelect limits) there's MSDN.
Take care,
Ger
On Thu, Aug 20, 2009 at 7:58 PM, Md Lazreg<mdlaz...@gmail.com> wrote:
> Hello,
>
> I have a Windows client that tries to connect to an SSL server using the
> following code :
>
> int status = ::connect( m_sock_fd,(sockaddr *)&m_addr,sizeof(m_addr));
> if (status == 0)
> {
> return true;
> }
> else
> {
> if (WSAGetLastError()== WSAEWOULDBLOCK)
> {
> struct timeval tv;
> tv.tv_sec = 20;
> tv.tv_usec = 0;
> fd_set myset;
> FD_ZERO(&myset);
> FD_SET(m_sock_fd, &myset);
> status = select(m_sock_fd+1, NULL, &myset, NULL, &tv);
> /*some other code here*/
> }
> else if (WSAGetLastError() == WSAECONNREFUSED)
> {
> return false;
> }
> else
> {
> /*some other code*/
> }
> }
>
> The socket I am using is NONBLOCKING.
>
> When my SSL server is up and running everything works as expected. When my
> SSL server is down, my client times out in 20 seconds because
> WSAGetLastError() returns WSAEWOULDBLOCK even when my server is not
> listening!
>
> I expect WSAGetLastError() to return WSAECONNREFUSED when my server is not
> listening...
>
> The problem I have with this is that my client is forced to wait for 20
> seconds before giving up. I expect it to return immediately if the SSL
> server is not listening...
>
> Am I missing something? Thanks.
>
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--------------------------------------------------
web: http://www.hobbelt.com/
http://www.hebbut.net/
mail: g...@hobbelt.com
mobile: +31-6-11 120 978
--------------------------------------------------
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
