Foundations of Python Network Programming 978-1-4302-3004-5

CHAPTER 2 ■ UDP
give us good practice with the Python network API before we move on to the additional complications
that are brought by the use of TCP.
Should You Read This Chapter?
Yes, you should read this chapter—and the next one on TCP—if you are going to be doing any
programming on an IP network. The issues raised and answered are simply too fundamental. A good
understanding of what is happening down at these low levels will serve you very well, regardless of
whether you are fetching pages from a web server, or sending complicated queries to an industrial
database.
But should you use what you learn in this chapter? Probably not! Unless you are talking to a service
that already speaks UDP because of someone else’s decision, you will probably want to use something
else. The days when it was useful to sit down with a UDP connection and bang out packets toward
another machine are very nearly gone.
The deployment of UDP is even rather dangerous for the general health of the IP network. The
sophisticated TCP protocol will automatically back off as the network becomes saturated and starts to
drop packets. But few UDP programmers want to even think about the complexity of typical congestionavoidance
algorithms—much less implement them correctly—with the result that a naively-written
application atop UDP can bring a network to its knees, flooding your bandwidth with an increasing
number of re-tries until almost no requests are actually getting through successfully.
If you even think you want to use the UDP protocol, then you probably want to use a message queue
system instead. Take a look at Chapter 8, and you will probably find that ØMQ lets you do everything you
wanted to accomplish with UDP, while having been programmed by people who dove far deeper into
the efficiencies and quirks of the typical operating system network stack than you could do without
months of research. If you need persistence or a broker, then try one of the message queues that come
with their own servers for moving messages between parts of your application.
Use UDP only if you really want to be interacting with a very low level of the IP network stack. But,
again, be sure to read this whole chapter either way, so that you know the details of what lies beneath
some of your favorite protocols like DNS, real-time audio and video chat, and DHCP.
Addresses and Port Numbers
The IP protocol that we learned about in Chapter 1 assigns an IP address—which traditionally takes the
form of a four-octet code, like 18.9.22.69—to every machine connected to an IP network. In fact, it does
a bit more than this: a machine with several network cards connected to the network will typically have a
different IP address for each card, so that other hosts can choose the network over which you want to
contact the machine. Multiple interfaces are also used to improve redundancy and bandwidth.
But even if an IP-connected machine has only one network card, we learned that it also has at least
one other network address: the address 127.0.0.1 is how machines can connect to themselves. It serves
as a stable name that each machine has for itself, that stays the same as network cables are plugged and
unplugged and as wireless signals come and go.
And these IP addresses allow millions of different machines, using all sorts of different network
hardware, to pass packets to each other over the fabric of an IP network.
But with UDP and TCP we now take a big step, and stop thinking about the routing needs of the
network as a whole and start considering the needs of specific applications that are running on a
particular machine. And the first thing we notice is that a single computer today can have many dozens
of programs running on it at any given time—and many of these will want to use the network at the same
moment! You might be checking e-mail with Thunderbird while a web page is downloading in Google
Chrome, or installing a Python package with pip over the network while checking the status of a remote
16