|Notes (handout)||Notes (overhead presentation)||Relevant textbook material|
|The client-server model||The client-server model||Chapter 2|
|Application program interfaces||APIs||Chapter 4, Chapter 5, part of Chapter 6|
|Client design||Client||Chapter 6 (the TCP part)|
|Server design||Server design||Chapters 8 (the TCP part) and 13; critical regions1|
|Multithreaded servers||Multithreaded servers||Chapter 122|
|Managing concurrency||Managing concurrency||Chapter 16|
|Multiservice servers||Multiservice servers||Chapter 15|
|Practical issues||Practical issues||Sections 30.1 to 30.23|
|Logging and debugging||Logging and debugging||The remainder of Chapter 30, extra|
|Deadlock and starvation||Deadlock and starvation||Chapter 31|
|Secure programming||Secure programming||Based on the Secure programs howto3|
|The User Datagram Protocol||UDP||Sections 6.18 to 6.24, 8.19, 8.22, 8.27, 8.28|
|The Internet Protocol||IP||RFC 791, routing algorithms extra|
|Socket programming on other platforms||Other platforms||N/A4|
|Multi-file programs||Multi-file programs||N/A5|
My lectures are recorded, as follows:
There are two videos for each recorded lecture, one featuring the camera feed and the other featuring a capture of the front desk screen. The audio track is the same for both videos. It is difficult to recommend one stream over another generally, since depending on the lecture things may happen on the screen or on the whiteboard. You may want to run both streams simultaneously (one of them muted).
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
to reuse the initially provided address. You can do this by
modifying the properties of the socket as follows (with
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
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.