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

CHAPTER 2 ■ UDP
them anywhere in the world for many years. An up-to-date (and typically much more extensive) copy is
also maintained online by the IANA at /www.iana.org/assignments/port-numbers.
The foregoing discussion, as we will learn in Chapter 3, applies equally well to TCP
communications, and, in fact, the IANA seems to consider the port-number range to be a single resource
shared by both TCP and UDP. They never assign a given port number to one service under TCP but to
another service under UDP, and, in fact, usually assign both the UDP and TCP port numbers to a given
service even if it is very unlikely to ever use anything other than TCP.
Sockets
Enough explanation! It is time to show you source code.
Rather than trying to invent its own API for doing networking, Python made an interesting decision:
it simply provides a slightly object-based interface to all of the normal, gritty, low-level operating system
calls that are normally used to accomplish networking tasks on POSIX-compliant operating systems.
This might look like laziness, but it was actually brilliance, and for two different reasons! First, it is
very rare for programming language designers, whose expertise lies in a different area, to create a true
improvement over an existing networking API that—whatever its faults—was created by actual network
programmers. Second, an attractive object-oriented interface works well until you need some odd
combination of actions or options that was perfectly well-supported by grungy low-level operating
system calls, but that seems frustratingly impossible through a prettier interface.
In fact, this was one of the reasons that Python came as such a breath of fresh air to those of us
toiling in lower-level languages in the early 1990s. Finally, a higher-level language had arrived that let us
make low-level operating system calls when we needed them without insisting that we try going through
an awkward but ostensibly “prettier” interface first!
So, Python exposes the normal POSIX calls for raw UDP and TCP connections rather than trying to
invent any of its own. And the normal POSIX networking calls operate around a central concept called a
socket.
If you have ever worked with POSIX before, you will probably have run across the fact that instead of
making you repeat a file name over and over again, the calls let you use the file name to create a “file
descriptor” that represents a connection to the file, and through which you can access the file until you
are done working with it.
Sockets provide the same idea for the networking realm: when you ask for access to a line of
communication—like a UDP port, as we are about to see—you create one of these abstract “socket”
objects and then ask for it to be bound to the port you want to use. If the binding is successful, then the
socket “holds on to” that port number for you, and keeps it in your possession until such time as you
“close” the socket to release its resources.
In fact, sockets and file descriptors are not merely similar concepts; sockets actually are file
descriptors, which happen to be connected to network sources of data rather than to data stored on a
filesystem. This gives them some unusual abilities relative to normal files. But POSIX also lets you
perform normal file operations on them like read() and write(), meaning that a program that just wants
to read or write simple data can treat a socket as though it were a file without knowing the difference!
What do sockets look like in operation? Take a look at Listing 2–1, which shows a simple server and
client. You can see already that all sorts of operations are taking place that are drawn from the socket
module in the Python Standard Library.
Listing 2–1. UDP Server and Client on the Loopback Interface
#!/usr/bin/env python
# Foundations of Python Network Programming - Chapter 2 - udp_local.py
# UDP client and server on localhost
import socket, sys
19