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 non-causal 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.
automatically generated by info2www version 18.104.22.168