while using net and stream socket, after client connect server, what should the server do when a conneceted client was force killed the process which both using tcp socket?
does the server know when a connected client was force killed the process?
The server knows when a client socket gets closed, which it implicitly does when the process owning the socket gets killed. The server does not get the reason why the socket gets closed though.
So there is no way for the server to react specifically at a socket close due to process killed. The server can only react to a socket closed at a time when the server does not expect the socket to get closed. How the server should react to this depends on the specific use case, i.e. there is no universal behavior.
Related
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?
We have an unix domain stream socket connection between client process -server process. When server is terminated, it is closing its connected sockets and its listening socket.
Sometimes, In client side, Socket is still in CONNECTED state (using netstat -anp | grep . Also, in client side, when recv() is called, it returns EAGAIN errno. This behavior is observed only SOMETIMES. But, not able to understand how this is possible.
If someone can explain how it is possible, then it would be really helpful.
Are you explicitly closing the connection?
If the server code is abruptly terminated without closing all connections, the operating system will still see this connection as active because the sever hasn't had time to clean up. The method to do this depends on the language used.
On the server side: I am using epoll_wait to monitor the possible read IO on a TCP socket.
On the client side: I have a single threaded app to write to the socket that's connected to the server.
The problem is, sometimes epoll_wait doesn't recognize there is new IO to read even after a new message is sent from the client. (I confirmed the message is indeed received by the server using wireshark) So the client is hanging waiting on the response from server. BUT: if I kill the client connection, epoll_wait does get notified!
Originally I am using EPOLLET and thought it would be a problem. But this issue still exists after removing EPOLLET.
Is there any tool that I can use to debug this? (e.g, outside of server process, to confirm that there is IO on the server socket queue but epoll_wait doesn't process it?) Any thought or guidance on how to debug this would be appreciated.
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