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 );
--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 Windows
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 put in
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, Windows
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 that for a
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
* 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 down
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
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
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 raw,
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)
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)
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
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
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
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
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
17 matches
Mail list logo
