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

CHAPTER 7 ■ SERVER ARCHITECTURE
5. Once this server has finished transmitting the answer, we tell the poll object to
swap the client socket back over to being listened to for new incoming data.
6. After many question-answer exchanges, the client will finally close the
connection. Oddly enough, the POLLHUP, POLLERR, and POLLNVAL circumstances
that poll() can tell us about—all of which indicate that the connection has
closed one way or another—are returned only if we are trying to write to the
socket, not read from it. So when an attempt to read returns zero bytes, we have
to tell the poll object that we now want to write to the socket so that we receive
the official notification that the connection is closed.
The performance of this vastly improved server design is shown in Figure 7–2. By the time its
throughput begins to really degrade, it has achieved twice the requests per second of the simple server
with which we started the chapter.
Figure 7–2. Polling server benchmark
Of course, this factor-of-two improvement is very specific to the design of this server and the
particular memory and processor layout of my laptop. Depending on the length and cost of client
requests, other network services could see much more or much less improvement than our Launcelot
service has displayed here. But you can see that a pure event-driven design like this one turns the focus
of your program away from the question of what one particular client will want next, and toward the
question of what event is ready to happen regardless of where it comes from.
Poll vs. Select
A slightly older mechanism for writing event-driven servers that listen to sockets is to use the select()
call, which like poll() is available from the Python select module in the Standard Library. I chose to use
112