The concurrent server
The four server models (iterative, one process per client, one thread per client or a thread pool, multiplexing with select), reaping children, closing descriptors and the limits of each model.
- 32 cards
- 5 topics
- Free
The outline, topic by topic
Each topic is weighted the way the exam weighs it.
- Concepts
- Questions
- Sort and link
- On the timeline
- Scenarios
A few cards from the deck
Iterative server: what is it?
Show the answer
A server that handles one client from start to finish before accepting the next, the others waiting in the queue.
It is the simplest to write:
accept, serve,close, repeat. A slow or silent client blocks everybody.An iterative server is serving a first client, which stays connected sending nothing. A second client connects. What does it observe?
- Its connection succeeds, but the server answers only after the first client leaves
- connect fails at once with “Connection refused”, since the server is already busy serving
- The server serves both clients in turn
- The second client takes the first one's place
Show the answer
Its connection succeeds, but the server answers only after the first client leaves
The kernel completes the handshake and puts the connection in
listen's queue. But the program only callsacceptafter finishing the first client: the second waits. That is the weakness of the iterative model.In a server with one process per client, the child closes the … socket and the parent closes the … socket.
Show the answer
In a server with one process per client, the child closes the listening socket and the parent closes the client's socket.
Each closes what it does not use. Otherwise the parent piles up client sockets until “Too many open files”, and a client's connection never really ends.
Concurrent server: what is it?
Show the answer
A server that takes charge of several clients at once, without waiting for one client to finish before answering another.
There are three ways to get it: several processes, several threads, or a single thread watching all the clients. Each has a cost and a limit.
After a few hours, a one-process-per-client server answers “accept: Too many open files”. What is the probable cause?
- Too many zombies have saturated the whole system's process table
- The parent never closes the client's socket after the fork
- The backlog value passed to listen is too large
- Clients do not close their own socket
Show the answer
The parent never closes the client's socket after the fork
Each
acceptcreates a descriptor in the parent, which stays open until the parent closes it, even when the child has finished. The per-process limit (often 1024) is eventually reached. Zombies would makeforkfail, notaccept.