Next: Code Up: Network Programming/Network Programming and Previous: Grading
My lectures are recorded as follows:
When you use the close command to close a socket your program tells the system that it is done with using the respective socket. The socket is however not deallocated, and even the port binding created by your program is still in place. Since nobody is using it, the port binding will eventually time out (according to the TCP timeout value, typically of the order of minutes) and die, but you get in the meantime slapped with an “port already in use” error if you want to bind another socket to the same port. This could become a serious nuisance when one uses thread preallocation, and especially when this is combined with dynamic reconfiguration.
This kind of behaviour occurs when the client does not shut down the socket. Indeed, the TCP stack on the server side assumes that communication will come from the client in the future unless the client has sent an end of file. But then the end of file is sent only upon shoudown. One solution is thus to convince one's clients to be well-behaved, but this is no real solution from the server's programmer point of view (typically the server's programmer has no control over the clients).
I could find no server-side solution to convince a socket to just die for good (should anybody know one, I would be very interested to hear about it). So I will present here the next best thing, a workaround. The workaround consists in convincing your socket to tell bind to reuse the initially provided address. You can do this by modifying the properties of the socket as follows (with sd the descriptor of your master socket):
int reuse = 1;
setsockopt(sd, SOL_SOCKET, SO_REUSEADDR, &reuse, sizeof(reuse));
This must be done after creating the socket and before binding it. See the manual page of socket in Section 7 for details on this and other options, and of course the manual page for setsockopt.
Finally, it is worth pointing out that when a client dies in an uncivilized manner the server receives a SIGPIPE signal from its TCP stack. This may be be used as well in the context of this problem (though I don't really know how).
You may also be interested in this explanation of what happens when a socket closes.
To better understand the concepts presented during the lectures. it may be a good idea to read the examples presented in the textbook for a supplementary (and sometimes alternative) view of the domain, as follows: