RE: WSAEWOULDBLOCK versus WSAECONNREFUSED

Md Lazreg wrote: > I am not saying that that is how it should behave. I am saying that > this is how it is behaving. With the above code and when my server > is down, my Windows client will output "Socket in the error set" only. > Which means that the socket was put in the ErrorSet and was not pu

Re: WSAEWOULDBLOCK versus WSAECONNREFUSED

--Original Message-- From: David Schwartz Sender: owner-openssl-us...@openssl.org To: openssl-users@openssl.org ReplyTo: openssl-users@openssl.org Subject: RE: WSAEWOULDBLOCK versus WSAECONNREFUSED Sent: Aug 24, 2009 11:14 AM Md Lazreg wrote: > It is possible that the previous Wind

Re: WSAEWOULDBLOCK versus WSAECONNREFUSED

Here is how my ErrorSet is constructed : fd_set WriteSet; FD_ZERO(&WriteSet); FD_SET(m_sock_fd, &WriteSet); fd_set ErrorSet; FD_ZERO(&ErrorSet ); FD_SET(m_sock_fd, &ErrorSet );

RE: WSAEWOULDBLOCK versus WSAECONNREFUSED

Md Lazreg wrote: > I do not know why you think my new change allows me to detect soft > failures. The only change I made is to change this: > status = select(m_sock_fd+1, NULL, &WriteSet, NULL, &tv); > to this: > status = select(m_sock_fd+1, NULL, &WriteSet, &ErrorSet, &tv); > Are you saying

Re: WSAEWOULDBLOCK versus WSAECONNREFUSED

I do not know why you think my new change allows me to detect soft failures. The only change I made is to change this: status = select(m_sock_fd+1, NULL, &WriteSet, NULL, &tv); to this: status = select(m_sock_fd+1, NULL, &WriteSet, &ErrorSet, &tv); Are you saying that for a soft failure, Windo

RE: WSAEWOULDBLOCK versus WSAECONNREFUSED

Md Lazreg wrote: > It is possible that the previous Windows behavior is correct but that > is not the behavior I want. I think you are incorrect about that. > I want the same behavior as UNIX which in my opinion is what my clients > would want. My clients can connect to a set of servers in a ra

Re: WSAEWOULDBLOCK versus WSAECONNREFUSED

With my new code, if my server is overloaded and cannot accept a connection immediately, my Windows client does not wait the whole timeout. This is the behavior I want. I do not want it to be sitting there just in case my server becomes available again or is on the process of being restarted. My o

RE: WSAEWOULDBLOCK versus WSAECONNREFUSED

Md Lazreg wrote: > 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]. That makes no sense. > My problem was that my select was

Re: WSAEWOULDBLOCK versus WSAECONNREFUSED

* David Schwartz wrote on Sun, Aug 23, 2009 at 15:40 -0700: > > 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

Re: WSAEWOULDBLOCK versus WSAECONNREFUSED

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

RE: WSAEWOULDBLOCK versus WSAECONNREFUSED

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 wh

Re: WSAEWOULDBLOCK versus WSAECONNREFUSED

Here is what MSDN says: http://msdn.microsoft.com/en-us/library/ms737625%28VS.85%29.aspx With a nonblocking socket, the connection attempt cannot be completed immediately. In this case, *connect* will return SOCKET_ERROR, and * WSAGetLastError* will return WSAEWOULDBLOCK

Re: WSAEWOULDBLOCK versus WSAECONNREFUSED

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 'conn

Re: WSAEWOULDBLOCK versus WSAECONNREFUSED

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

Re: WSAEWOULDBLOCK versus WSAECONNREFUSED

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

Re: WSAEWOULDBLOCK versus WSAECONNREFUSED

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)