I'm writing an application that attempts to do the following:
create a TCP server listening on an available port
create a TCP socket that connects to the server
have the server socket write data to the client
have the server socket close its end of the connection
have the client write a message to the server
Here's where the problem lies. When I attempt to run the application, the TCP exchange goes like this:
The first three packets establish the three-way handshake, and the fourth and fifth packets are the transmission of the data written by the server and its acknowledgement.
As expected, the server socket sends a packet with the FIN flag set to indicate that it is closing its end of the connection. The client acknowledges this and then attempts to write its data to the socket. The server immediately sends an RST packet, terminating the connection prematurely.
Why does this happen?
Note: the above capture was done on Windows 8.1.
The sender cannot send data after a [FIN]. Such an action will result in the receiver issuing an [RST].
The FIN probably indicates that the server has fully closed the connection in both directions. In this case if it receives any further data on the connection it will issue an RST. This suggests an application protocol error on your part. If the server sends a reply and then closes the socket, the client can't send anything else via that connection.
Possibly you need your server to call shutdown() with SHUT_WR and then read something else from the client before closing the socket. Or possibly you're just doing it wrong.
Related
I am working on a product which uses ZeroMQ (version 4.0.1).
The server and client communicate based on ZeroMQ ROUTER-socket.
To read socket events, server and client also create socket-monitor sockets (PAIR). There are three ports on which server binds and listens. Out of these three ports, one port is in a non-secured mode. Other two ports are using md5-authentication.
The issue I am facing is that, both the server and the client spontaneously receive socket disconnect for one of the secure port sockets (please see a log below). I have checked multiple times that server and client both have L3 reachability to each other.
What else I should check for?
What really triggers this error scenario?
zmq_print_callback:ZmQ: int zmq::stream_engine_t::read(void*, size_t):923
Stream engine recv():
TCP socket (187) to unknown:0 was disconnected
with error 107 [Transport endpoint is not connected]
Below sequence of events can trigger this error on server
Server receives ACCEPTED event for clientY and gets FD1.
Link-flap/network issue happens and clientY disconnects but server does not receive this disconnect.
Network recovers and clientY connects back to server.
Server receives ACCEPTED event for clientY and gets FD2. However, packets sent to this sockets does not go out of the server.
After 1 min or so, clientY receives "Transport endpoint is not connected error" for FD1.
Application can use this to treat as client disconnect.
I have a system with server/client applications. The client will send in socket connection request and the server will accept the socket connection when it's working correctly. However, in some situations (most likely due to ungraceful socket disconnection like system shutdown on client side or crash), the client will not be able to reconnect to the server application. The Wireshark capture shows the client will continue to try to connect; but after going through SYN->SYN,ACK->ACK, the server application will send RST. At this point, sometimes the netstat -an will show the connection is in CLOSE_WAIT state and other times would not show this connection. The capture shows 'Acknowledgment Number: Broken TCP. The ackowledge field is nonzero while the ACK flag is not set.
My questions is why the server application would send this RST?
There is delay seen on server machine while sending [SYN,ACK] packet to Client machine for the first connection attempt from client. These are some observations analyzed with sniffer tool wireshark:-
Due to this delay:-
Client application is sending the [TCP Retransmission] packet to server.
Later, connection timeout expires(3 seconds) on client side and it tries second connection attempt with server.
Surprisingly, server immediately sends [SYN,ACK] packet for second connection attempt to client back.
After sending [SYN,ACK] packet for second attempt, server responds back with [SYN,ACK] packet for the first attempt.
For better understanding, client application sends the connection request certain set server ports all together. Server sends [SYN,ACK] packet from the listening port which is one of these ports.
I will be pleased if somebody explains :-
Why there is delay in [SYN,ACK] packet from server machine?
Why server able to respond back immediately with [SYN,ACK] packet for second attempt but responded for first connection attempt after sending [SYN,ACK] for first attempt.
Who takes care of responding back [SYN,ACK] packet to client machine? Is it server application or any other operating system service?
The screenshot of wireshark is attached here. The above mentioned observation is on the basis of frame#20145 to Frame#20428
I have a client-server (Java) application using persistent TCP connections, but sometimes the Server receives java.io.IOException: Connection reset by peer exception when trying to write on the socket, however I don't see any error in the Client log.
This RST is probably caused by an intermediate proxy/router, but if that's the case, should this be seen on the client as well?
If the RST is sent by the client, it can be seen on it using a packet sniffer such as wireshark. However, it won't show up in any user-level sockets since it's sent by the OS as a response to various erroneous inputs (such as connection attempts to a closed port).
If the RST is sent by the network, then it's pretending to be the client to sever the connection. It can do so in one direction, or in both of them. In that case, the client might not see anything, except for a RST sent by the actual server when the client continues to send data to a connection it perceives as open, while the server sees it as closed.
Try capturing the traffic on both the server and the client, see where the resets are coming from.
I am trying to wrap my head around network sockets. So far my understanding is that a server creates a new socket that is bound to the specific port. Then it listens to this socket to deal with client requests.
I've read this tutorial http://docs.oracle.com/javase/tutorial/networking/sockets/definition.html and it says
If everything goes well, the server accepts the connection. Upon acceptance,
the server gets a new socket bound to the same local port and also has
its remote endpoint set to the address and port of the client. It needs
a new socket so that it can continue to listen to the original socket for
connection requests while tending to the needs of the connected client.
Here are a few things that I don't quite understand
If everything goes well, the server accepts the connection.
Does it mean that a client request successfully arrived at the listening socket?
Upon acceptance, the server gets a new socket bound to the same local port and
also has its remote endpoint set to the address and port of the client
The new socket is created. It also gets bound to the same port but it doesn't listen for incoming requests. After server processed client request resonse is written to this socket and then it gets closed. Is it correct?
Does it mean that request is somehow passed from the first socket to the second socket?
It needs a new socket so that it can continue to listen to the original
socket for connection requests while tending to the needs of the connected client.
So, the new socket is created then that listens for incoming request. Are there different type of sockets? Some kind of "listening" sockets and other?
Why does the server have to create a new listening socket? Why can't it reuse the previous one?
No. It means that an incoming connection arrived at the server.
No. It gets closed if the server closes it. Not otherwise.
No. It means that the incoming connection causes a connection to be fully formed and a socket created at the server to represent the server-end endpoint of it.
(a) No. A new socket is created to receive requests and send responses. (b) Yes. There are passive and active sockets. A passive socket listens for connections. An active socket sends and receives data.
It doesn't have to create a new listening (passive) socket. It has to create a new active socket to be the endpoint of the new connection.
Is new socket created for every request?
Most protocols, for example HTTP with keep-alive, allow multiple requests per connection.
1) An incoming connection has arrived
2) Socket doesn't get closed
3) There is server socket and just socket. Server socket.accept returns a socket object when a client connects