Thank you Ger for your reply.
It is true that by using a nonblocking connect I want an instant answer but most importantly I want a correct answer. Using the same code under UNIX I get two instant correct answers: ECONNREFUSED [If my SSL server is down] EINPROGRESS [If my SSL server is up and listening] But under Windows I get the same answer regardless of the state of my SSL server: WSAEWOULDBLOCK My question is why _using the same code_ Windows is returning WSAEWOULDBLOCK instead of WSAECONNREFUSED when my server is down? while UNIX correctly returns ECONNREFUSED... Thanks On Sun, Aug 23, 2009 at 5:04 PM, Ger Hobbelt <g...@hobbelt.com> wrote: > 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 > >
