How does closing a socket affects other's side read

Question

For example we have a client-server application. If the server writes a message on the socket and then closes it before the client's read. Will the client be able to read the message?

Answer 1

This behavior is implementation specific, in general, you should not assume the client is able to read the message, the close(2) in the Linux manual says:

Be sure to use shutdown(2) to shut down all parts the connection before closing the socket.

If you want to ensure that a client has read that message, make that client acknowledge that action in your application protocol.

When you send data through the socket and then you close that same socket, there's no guarantee that the kernel has emptied it's internal buffers to the network or even could do so (eventual problematic network conditions).

Answer 2

When we close a connection using the close function, we risk aborting it. This means that the other side will not read all the data we have previously queued into the socket.

The proper way to close the connection is to perform a half-close with the shutdown function, and then continue to read the data until the end.

In specific scenarios, the need for the half-close can be omitted by one of the peers.

Say we have a protocol like this: client connects to a server, asks a question and obtains a response. Then the two disconnect.

In this scenario, the client will send the question, and perform a half-close with shutdown to indicate the end of the data to the server. The server reads the question, and notices that the connection has ended from the client side. It then produces a response, writing it to the socket. In this situation, the server can get away with doing a close. The TCP stack will not abort the connection because it knows it has ended from the client side; i.e. the server is not ignoring data from the client. What will happen is that the operating system will dispose of the socket descriptor, but the TCP stack will then continue the closure of the connection in the background: send the FIN to the client and receive the ACK and so on.

The situation we have to watch out for is doing a close, without having read all the data from the remote end. That situation indicates we are not interested in communicating. Not being interested in reading the remote peer's data indicates that we don't care about communicating with it, and therefore any queued data we sent to that peer also doesn't matter.

In a protocol in which the client can stay connected and make multiple requests, we cannot use close on the server side, because that will generate an abort which will throw away part of a reply that was sent. We must use a graceful half-close to indicate to the client that we won't be taking any more requests on the current connection. That ensures the client will receive the entire response to the previous request, detect the end of the stream, and then itself disconnect. In that situation, if the client has started sending a new request before receiving the full response to the last one that the server will process, that new request will be lost. The server can gracefully read all such rejected requests to the end of the stream, throw them away, and then close the connection fully. Having decided to half-closed the connection, it has no way to reply to those extra requests.

In this kind of situation where a client can make multiple requests, it may be best not to ever initiate a close of the connection from the server side, other than if the server has to be restarted (in which case it will be abortive). That is to say, we let the client control the the session termination. The client connects and makes numerous requests, obtaining replies to them. When the client decides that a certain request will be the last one, it half-closes the connection. Then the situation proceeds exactly like in the first example above of the single request scenario.

Answer 3

"If the server writes a message on the socket and then closes it before the client's read. Will the client be able to read the message?"

Yes. The client will get the data that was sent before the FIN packet that closes the socket.