[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.