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

CHAPTER 7 ■ SERVER ARCHITECTURE
» » client_sock, sockname = listen_sock.accept()
» » handle_client(client_sock)
if __name__ == '__main__':
» listen_sock = launcelot.setup()
» server_loop(listen_sock)
Note that the server is formed of two nested loops. The outer loop, conveniently defined in a
function named server_loop() (which we will use later in some other program listings), forever accepts
connections from new clients and then runs handle_client() on each new socket—which is itself a loop,
endlessly answering questions that arrive over the socket, until the client finally closes the connection
and causes our recv_until() routine to raise EOFError.
By the way, you will see that several listings in this chapter use additional ink and whitespace to
include __name__ == '__main__' stanzas, despite my assertion in the preface that I would not normally do
this in the published listings. The reason, as you will soon discover, is that some of the subsequent
listings import these earlier ones to avoid having to repeat code. So the result, overall, will be a savings in
paper!
Anyway, this simple server has terrible performance characteristics.
What is wrong with the simple server? The difficulty comes when many clients all want to connect at
the same time. The first client’s socket will be returned by accept(), and the server will enter the
handle_client() loop to start answering that first client’s questions. But while the questions and
answers are trundling back and forth across the network, all of the other clients are forced to queue up
on the queue of incoming connections that was created by the listen() call in the setup() routine of
Listing 7–1.
The clients that are queued up cannot yet converse with the server; they remain idle, waiting for
their connection to be accepted so that the data that they want to send can be received and processed.
And because the waiting connection queue itself is only of finite length—and although we asked for
a limit of 128 pending connections, some versions of Windows will actually support a queue only 5 items
long—if enough incoming connections are attempted while others are already waiting, then the
additional connections will either be explicitly refused or, at least, quietly ignored by the operating
system. This means that the three-way TCP handshakes with these additional clients (we learned about
handshakes in Chapter 3) cannot even commence until the server has finished with the first client and
accepted another waiting connection from the listen queue.
An Elementary Client
We will tackle the deficiencies of the simple server shown in Listing 7–2 in two discussions. First, in this
section, we will discuss how much time it spends waiting even on one client that needs to ask several
questions; and in the next section, we will look at how it behaves when confronted with many clients at
once.
A simple client for the Launcelot protocol is shown in Listing 7–3. It connects, asks each of the three
questions once, and then disconnects.
Listing 7–3. A Simple Three-Question Client
#!/usr/bin/env python
# Foundations of Python Network Programming - Chapter 7 - client.py
# Simple Launcelot client that asks three questions then disconnects.
import socket, sys, launcelot
def client(hostname, port):
102