Chapter 2 ■ UDp27However, often it will find that one or more of its requests never results in replies, and it will have to retry. If you
watch its repeated attempts carefully, you can even see the exponential backoff happening in real time, as the print
statements that echo to the screen come more and more slowly as the delay timer ramps up.
$ python udp_remote.py client guinness
Client socket name is ('127.0.0.1', 58414)
Waiting up to 0.1 seconds for a reply
Waiting up to 0.2 seconds for a reply
Waiting up to 0.4 seconds for a reply
Waiting up to 0.8 seconds for a reply
The server says 'Your data was 23 bytes long'
You can see in the terminal where you are running the server whether the requests are actually making it or
whether, by any chance, you hit a real packet drop on your network. When I ran the foregoing test, I could look over at
the server’s console and see that all of the packets had actually made it.
Pretending to drop packet from ('192.168.5.10', 53322)
Pretending to drop packet from ('192.168.5.10', 53322)
Pretending to drop packet from ('192.168.5.10', 53322)
Pretending to drop packet from ('192.168.5.10', 53322)
The client at ('192.168.5.10', 53322) says, 'This is another message'
What if the server is down entirely? Unfortunately, UDP gives us no way to distinguish between a server that
is down and a network that is simply in such poor condition that it is dropping all of our packets or their replies. Of
course, I suppose we should not blame UDP for this problem. The world itself, after all, gives us no way to distinguish
between something that we cannot detect and something that does not exist! So, the best that the client can do is to
give up once it has made enough attempts. Kill the server process, and try running the client again.
$ python udp_remote.py client guinness
Client socket name is ('127.0.0.1', 58414)
Waiting up to 0.1 seconds for a reply
Waiting up to 0.2 seconds for a reply
Waiting up to 0.4 seconds for a reply
Waiting up to 0.8 seconds for a reply
Waiting up to 1.6 seconds for a reply
Traceback (most recent call last):
...
socket.timeout: timed out
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
...
RuntimeError: I think the server is down