you might have to know and type the HTTP port number of every site you visit while
surfing the Net.
By defining standard port numbers for services, the Net naturally gives rise to a client/
server architecture. On one side of a conversation, machines that support standard
protocols perpetually run a set of programs that listen for connection requests on the
reserved ports. On the other end of a dialog, other machines contact those programs
to use the services they export.
We usually call the perpetually running listener program a server and the connecting
program a client. Let’s use the familiar web browsing model as an example. As shown
in Table 12-1, the HTTP protocol used by the Web allows clients and servers to talk
over sockets on port 80:
Server
A machine that hosts websites usually runs a web server program that constantly
listens for incoming connection requests, on a socket bound to port 80. Often, the
server itself does nothing but watch for requests on its port perpetually; handling
requests is delegated to spawned processes or threads.
Clients
Programs that wish to talk to this server specify the server machine’s name and
port 80 to initiate a connection. For web servers, typical clients are web browsers
like Firefox, Internet Explorer, or Chrome, but any script can open a client-side
connection on port 80 to fetch web pages from the server. The server’s machine
name can also be simply “localhost” if it’s the same as the client’s.
In general, many clients may connect to a server over sockets, whether it implements
a standard protocol or something more specific to a given application. And in some
applications, the notion of client and server is blurred—programs can also pass bytes
between each other more as peers than as master and subordinate. An agent in a peer-
to-peer file transfer system, for instance, may at various times be both client and server
for parts of files transferred.
For the purposes of this book, though, we usually call programs that listen on sockets
servers, and those that connect clients. We also sometimes call the machines that these
programs run on server and client (e.g., a computer on which a web server program
runs may be called a web server machine, too), but this has more to do with the physical
than the functional.
Protocol structures
Functionally, protocols may accomplish a familiar task, like reading email or posting
a Usenet newsgroup message, but they ultimately consist of message bytes sent over
sockets. The structure of those message bytes varies from protocol to protocol, is hidden
by the Python library, and is mostly beyond the scope of this book, but a few general
words may help demystify the protocol layer.
784 | Chapter 12: Network Scripting