Probably the difference is due to timing; to get the connection refused response, the client needs to at least transmit a packet and either never see a response (timing out) or receive a RST or (in some cases) an ICMP host-unreachable packet. Any way, the minimum time required to give you the 'connection refused' response is two network travels at the absolute minimum. Which means: it takes time.
'nonblocking' simply means 'I don't want to wait', so theoretically the IP stack doesn't have to wait even a milli/micro/femtosecond before returning to you. Which is what winsock does: queue request, instant return, hence wouldblock. Apparently (and this can be due to a myriad of reasons) your UNIX box either already 'knows' the server is down or has an IP stack which waits a short while before returning from connect, even in nonblocking conditions, so it is able to deliver a 'connection refused' to you on the initial return. > It is true that by using a nonblocking connect I want an instant answer but > most importantly I want a correct answer. The answer is correct, because the answer is depending on time. This may sound weird to you as it looks like the whole time/async behaviour pattern here are what's troubling you, but the nonblocking means the 'wouldblock' behaviour is the behaviour you would /expect/ from the system; the fact that the other machine isn't doing this is, at best, something to frown and ponder. /That/ one worries me, not the Win box. How can that machine know /instantaneously/ that the server at other end of the wire is down? There's no paranormal vibe there, so... is it's IP stack implemented to wait /anyway/ (bad!), despite the fact that it knows it's got a nonblocking request from the application? Is it at all /aware/ that this is a nonblocking handle/request here?! Or more obscure and less probable: Is it caching icmp or other previous responses regarding availability of other machines and shortcircuiting the request due to that cached info? etc. (Or is the unix box the server and client both, i.e. connection to localhost or eqv., so the IP stack can short-circuit the request that way?) Your issue is, IMO, not the wouldblock, but the connrefused, which is unexpected for a truely nonblocking socket. I checked my specs, and I was correct in saying that you need to check for a READ event in select() to get a notification about a completed nonblocking connect, both on UNIX and WinSock. While you don't do that (you only ask select() about WRITE events there) the select() will sit an pick it's nose until timeout. Again, nonblocking is you telling the kernel 'go fetch, while I do other stuff at the same time' and the /direct/ return of connrefused only means one thing: the bastard is forcing you to wait anyhow until the system/kernel is done doing its thing, which is /precisely/ what you said, through NONblocking, you do NOT want (the waiting on the call to finish). Either that or the unix box has obtained precognition, which is a bit worrysome in its own way. PS: are you addressing the server by IP number or domain name? In the latter case, have you made sure the DNS request which converts the FQDN to an IP produced a positive result? In other words: is connect being fed a usable IP number and ditto port on both boxes? Are those numbers identical on both boxes? Just making sure here as the immediate connection refused is suspect. On Sun, Aug 23, 2009 at 5:35 PM, Md Lazreg<mdlaz...@gmail.com> wrote: > 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 >> > > -- 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
