I am trying to connect to a server on another machine via a non-blocking connect().
However, when I do so, Connect() returns -1, and I receive WSAEWOULDBLOCK from WSAGetLastError().
MSDN Documentation states that: It is normal for WSAEWOULDBLOCK to be reported as the result from calling connect on a nonblocking SOCK_STREAM socket, since some time must elapse for the connection to be established (reference).
The issue is that I am always receiving the error, and -1 is returned from connect() EVEN IF my server is not running.
My socket is a SOCK_STREAM socket, just as suggested. How might I remedy this? Should I provide a timeout after the connect() call to ensure that enough time is given for connect to establish a connection?
Use ConnectEx and pass the OVERLAPPED structure. That way you can retrieve the actual status later, when the connection attempt finishes.
Related
I've a client server model operating in non blocking mode where the server is as usual trying to accept connections infinitely. And client is repeatedly trying to connect with the server until it succeeds.
When I run the server first and then client, I can see logs on server that the accept() call was a success but on client side the connect() call is failing with an error code 10035.
Overall files are a lot bigger than than this and there's so much going on in them. Both server & client are actually packet sniffers and the problematic part is when I try to establish a connection between these 2 sniffers to transfer information.
Error code 10035 is WSAEWOULDBLOCK (table), which means the connection did not fail -- it just hasn't completed yet, and you need to wait a bit.
Normally one will wait until the socket is writable or has an error condition after issuing a connect that returns this code -- once one of those two things happen, you know the connection has either completed or failed for some other reason. You can do that wait with a select call with the descriptor included in 'writefds' and 'exceptfds' arguments.
According to me connect() takes some time to establish a connection thus you cannot have it running in non blocking mode. And server is showing no error in accept() is because of the following reason:
3 way handshake:
Client sends SYN flag to the server
And server responds with SYN-ACK and when server acknowledges, it returns success from accept()
BUT, to complete 3 way handshake, client must send an ACK back to the server which it fails to do because of non blocking mode, thus connect() fails.
Note: This is for nonblocking sockets.
According to
MSDN's select() documentation,
the exceptfds parameter can only monitor
failed connection attempts via connect()
Out of Band data
If I am not ever using OOB data, and the server never calls connect() to connect to anything, but only calls accept() for incoming connections, send() to send data to connections, and recv() to read data from connections, should the server therefore never monitor for exceptions when calling select()?
I was advised to still monitor for exceptions via exceptfds when select()'ing, but it looks like there is nothing that could possible cause an exception, according to the MSDN documentation.
Should I recreate the whole socket when a server was rebooted and client received WSAECONNRESET error code on the last call to send function? It seems that I am unable to just call the connect function on the same socket again -- it will fail with WSAEISCONN error code over and over again. Am I need to call closesocket and create SOCKET again with the socket function then?
Once a socket connection has been disconnected, you must close the SOCKET handle and create a new one. The only exception to this is if you use DisconnectEx() with the TF_REUSE_SOCKET flag, then the SOCKET can be reused with ConnectEx() or AcceptEx().
When I do the following steps to receive a message and send a reply, it fails.
I am using TCP. I need the program to send data from the same port it received from.
bind()
listen()
accept()
recv()
connect()//it fails to connect here using the same socket.<br>
send()
It seems you have a problem in understanding the way tcp works. There is a server and a client. The server waits for connections, and the client makes connections. Once a connection is established, the server and the client can communicate bi-directional (i.e. both can send and recive messages). Of course, their role might change, but this is the way it works. So, the server does:
bind()
listen()
accept()
recv()
send()
It is stuck at accept() until a client performs connect() on the port that the server is listening to.
As my explanation is pretty brief, I suggest you read this tutorial about linux sockets.
In my C++ application I'm using network connection (TCP).
when I'm identify a network connection error I'm trying to connect to another interface.
in the reconnection the connect function has passed with no error but on send function it return an SOCKET_ERROR and WSGetLastError return 10054.
do you know what is the meaning of this error and what should I do to resolve it?
10x
10054 means connection reset by peer -- the remote endpoint replied with an RST packet to tell you that the connection isn't open. Reconnect with connect() instead of trying to simply change interfaces on your local end.
10054 (connection reset by peer) after successfull connect() means that the server accepts incoming connection but after that it closes the accepted socket without waiting for incoming information. The only way to resolve this is to check the server application logic.