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

CHAPTER 2 ■ UDP
So binding to an IP interface might limit which external hosts can talk to you; but it will certainly not
limit conversations with other clients on the same machine, so long as they know the IP address that
they should use to connect.
Second, what happens if we try to run two servers at the same time? Stop all of the scripts that are
running, and we can try running two servers on the same box. One will be connected to the loopback:
$ python udp_remote.py server 127.0.0.1
Listening at ('127.0.0.1', 1060)
And then we try running a second one, connected to the wildcard IP address that allows requests
from any address:
$ python udp_remote.py server
Traceback (most recent call last):
...
socket.error: [Errno 98] Address already in use
Whoops! What happened? We have learned something about operating system IP stacks and the
rules that they follow: they do not allow two different sockets to listen at the same IP address and port
number, because then the operating system would not know where to deliver incoming packets. And
both of the servers just shown wanted to hear packets coming from the localhost to port 1060.
But what if instead of trying to run the second server against all IP interfaces, we just ran it against
an external IP interface—one that the first copy of the server is not listening to? Let us try:
$ python udp_remote.py server 192.168.5.130
Listening at ('192.168.5.130', 1060)
It worked! There are now two servers running on this machine, one of which is bound to the inwardlooking
port 1060 on the loopback interface, and the other looking outward for packets arriving on port
1060 from the network to which my wireless card has connected. If you happen to be on a box with
several remote interfaces, you can start up even more servers, one on each remote interface.
Once you have these servers running, try to send them some packets with the client program. You
will find that each request is received by only one server, and that in each case it will be the server that
holds the particular IP address to which you have directed the UDP request packet.
The lesson of all of this is that an IP network stack never thinks of a UDP port as a lone entity that is
either entirely available, or else in use, at any given moment. Instead, it thinks in terms of UDP “socket
names” that are always a pair linking an IP interface—even if it is the wildcard interface—with a UDP
port number. It is these socket names that must not conflict among the listening servers at any given
moment, rather than the bare UDP ports that are in use.
One last warning: since the foregoing discussion indicated that binding your server to the interface
127.0.0.1 protects you from possibly malicious packets generated on the external network, you might
think that binding to one external interface will protect you from malicious packets generated by
malcontents on other external networks. For example, on a large server with multiple network cards, you
might be tempted to bind to a private subnet that faces your other servers, and think thereby that you
will avoid spoofed packets arriving at your Internet-facing public IP address.
Sadly, life is not so simple. It actually depends on your choice of operating system, and then upon
how it is specifically configured, whether inbound packets addressed to one interface are allowed to
appear at another interface. It might be that your system will quite happily accept packets that claim to
be from other servers on your network if they appear over on your public Internet connection! Check
with your operating system documentation, or your system administrator, to find out more about your
particular case. Configuring and running a firewall on your box could also provide protection if your
operating system does not.
29