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
