Thanks all. Both UNIX and Windows will return EINPROGRESS and WSAEWOULDBLOCK successively after a non blocking connect. [I was confused about this before but now I understand it.]
The difference between UNIX and Windows is in the select system call that comes after the connect call. On UNIX the select will return after signaling the write set [ as documented]. On Windows the select will return after signaling the _error_ set [The MSDN documentation says that you need to check the write set]. My problem was that my select was checking only for write-ability [which is what the documentation says for both Windows and UNIX]. So on Windows I was forced to timeout while on UNIX I was returning immediately. Now I changed my select to check for both write-ability and error-ability on Windows. Then I call getsockopt which returns WSAECONNREFUSED as I have been expecting. Thanks again. On Mon, Aug 24, 2009 at 12:40 AM, David Schwartz <dav...@webmaster.com>wrote: > > Md Lazreg wrote: > > > 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. > > Why? The SSL server might be restarting. Perhaps it will be listening again > in a second or two. It takes as long as it takes to ensure that the server > is not listening and will not resume listening. > > This is one of the differences between Windows and traditional UNIX > systems. > On Windows, if a server is overloaded, it refuses connections rather than > silently ignoring them. As a result, when a client gets a connection > refused, it cannot assume the server is not listening. It's possible the > server is overloaded. So it has to try again, which takes some time. > > > 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... > > Because Windows cannot tell whether your server is down or overloaded. UNIX > assumes that it is down, which may or may not be correct. > > The Windows client behavior you are seeing is correct, but only because it > is assuming Windows server behavior that is incorrect. The UNIX behavior is > incorrect -- it cannot be sure your server is actually down, but assumes so > anyway -- but only because it assumes the server will behave correctly. > > Because Windows servers do not behave correctly, Windows clients are forced > to behave incorrectly. I have yet to figure out why things are this way, > but > this is the way they are. It appears to be a deliberate Microsoft decision > that we all have to live with. > > The summarize: When Windows server are overloaded, they reject connections > rather than ignoring them. Thus, a client that sees a rejected connection > cannot be sure the server is not running -- it could just be overloaded. > (So > you are correctly told the connection could not be made at that time, but > might succeed later.) > > It's also possible the server is restarting, and will be accepting > connections again in a second or two. The Windows client checks for this as > well. > > DS > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
