2.11 Network Programming Caveats

By now it should be clear
that debugging a networked application is more
complicated than debugging a single-process single-hosted application.
The behavior of a networked application sometimes looks noncausal because
it is not reproducible in a strong sense. Whether a network application
works or not sometimes depends on the following:

How crowded the underlying network is

If the party at the other end is running or not

The state of the party at the other end

The most difficult problems for a beginner arise from the hidden states of the
underlying network. After closing a TCP connection, it’s often necessary to wait
a short while before reopening the connection. Even more difficult is the
establishment of a connection that previously ended with a “broken pipe.”
Those connections have to “time out” for a minute or so
before they can reopen.
Check this with the command ‘netstat -a’, which
provides a list of still “active” connections.