close vs shutdown socket?
None of the existing answers tell people how shutdown
and close
works at the TCP protocol level, so it is worth to add this.
A standard TCP connection gets terminated by 4-way finalization:
- Once a participant has no more data to send, it sends a FIN packet to the other
- The other party returns an ACK for the FIN.
- When the other party also finished data transfer, it sends another FIN packet
- The initial participant returns an ACK and finalizes transfer.
However, there is another "emergent" way to close a TCP connection:
- A participant sends an RST packet and abandons the connection
- The other side receives an RST and then abandon the connection as well
In my test with Wireshark, with default socket options, shutdown
sends a FIN packet to the other end but it is all it does. Until the other party send you the FIN packet you are still able to receive data. Once this happened, your Receive
will get an 0 size result. So if you are the first one to shut down "send", you should close the socket once you finished receiving data.
On the other hand, if you call close
whilst the connection is still active (the other side is still active and you may have unsent data in the system buffer as well), an RST packet will be sent to the other side. This is good for errors. For example, if you think the other party provided wrong data or it refused to provide data (DOS attack?), you can close the socket straight away.
My opinion of rules would be:
- Consider
shutdown
beforeclose
when possible - If you finished receiving (0 size data received) before you decided to shutdown, close the connection after the last send (if any) finished.
- If you want to close the connection normally, shutdown the connection (with SHUT_WR, and if you don't care about receiving data after this point, with SHUT_RD as well), and wait until you receive a 0 size data, and then close the socket.
- In any case, if any other error occurred (timeout for example), simply close the socket.
Ideal implementations for SHUT_RD and SHUT_WR
The following haven't been tested, trust at your own risk. However, I believe this is a reasonable and practical way of doing things.
If the TCP stack receives a shutdown with SHUT_RD only, it shall mark this connection as no more data expected. Any pending and subsequent read
requests (regardless whichever thread they are in) will then returned with zero sized result. However, the connection is still active and usable -- you can still receive OOB data, for example. Also, the OS will drop any data it receives for this connection. But that is all, no packages will be sent to the other side.
If the TCP stack receives a shutdown with SHUT_WR only, it shall mark this connection as no more data can be sent. All pending write requests will be finished, but subsequent write requests will fail. Furthermore, a FIN packet will be sent to another side to inform them we don't have more data to send.
There are some limitations with close()
that can be avoided if one uses shutdown()
instead.
close()
will terminate both directions on a TCP connection. Sometimes you want to tell the other endpoint that you are finished with sending data, but still want to receive data.
close()
decrements the descriptors reference count (maintained in file table entry and counts number of descriptors currently open that are referring to a file/socket) and does not close the socket/file if the descriptor is not 0. This means that if you are forking, the cleanup happens only after reference count drops to 0. With shutdown()
one can initiate normal TCP close sequence ignoring the reference count.
Parameters are as follows:
int shutdown(int s, int how); // s is socket descriptor
int how
can be:
SHUT_RD
or 0
Further receives are disallowed
SHUT_WR
or 1
Further sends are disallowed
SHUT_RDWR
or 2
Further sends and receives are disallowed
This is explained in Beej's networking guide. shutdown
is a flexible way to block communication in one or both directions. When the second parameter is SHUT_RDWR
, it will block both sending and receiving (like close
). However, close
is the way to actually destroy a socket.
With shutdown
, you will still be able to receive pending data the peer already sent (thanks to Joey Adams for noting this).