Like an office receptionist, a network server application can choose different strategies for answering incoming connection requests and dispatching them to workers. Before we get to the actual code, let's discuss three possible strategies. Later, we'll show code for two receptionists: the sequential receptionist and the event-driven receptionist.
A sequential receptionist uses a strategy similar to that employed by some parents of teenage children with a single phone line. Connection requests are handled in the sequence they arrive, one at a time. When a call comes in, the sequential receptionist answers the call, figures out who the call is meant for, and passes it on. While the call is in progress, no other calls are answered. The receptionist waits for the worker (that's the teenager) to finish with the call (and forget to hang up), then closes the connection (hangs up the phone), and waits for the next call.
The main advantage of the sequential receptionist is that it is easy to code. One call at a time implies only one thread, which means we don't have to worry about synchronizing access to shared data. Waiting for the call to complete can be done with standard procedural control flow: just call a subroutine which handles the call. The receptionist gets the thread of control back when the worker subroutine is finished.
The big disadvantage of the sequential receptionist is that only one call at a time is handled. If two calls arrive at once, somebody has to wait. If the worker waits for the caller to transmit data (blocks on read), and the caller for some reason never transmits the data, then the server may wait forever. Other calls will never get answered. Time to hire a new receptionist.
The concurrent receptionist is a lot like the sequential receptionist except for one thing. This receptionist has figured out that one of the big limitations of the sequential receptionist is that there is often only one line for handling calls.
The concurrent receptionist gets around this problem by cloning a new worker for each incoming call. Once the worker is cloned, the receptionist passes on the call, tells the worker to get to work, leaves the worker with the caller, and goes back to watching the phone.
This strategy fixes the biggest problem we had before: we can now handle more than one incoming call at a time. If an incoming call makes a worker wait, it doesn't affect the receptionist, since the receptionist has already gone back to watching the phone. The price is that our application now has multiple threads of control, and so we have to worry about synchronizing access to shared data, and keeping track of multiple worker clones each running in their own thread.
There are different methods of implementing the concurrent receptionist, depending on which model of concurrency is being used. Under Unix, many network daemons are implemented in this style, where the concurrency is provided by forking off a new process for each incoming call. For lightweight protocols, or for servers that need to access shared data, the concurrent receptionist could be implemented using threads.
The event-driven receptionist likes to maintain complete control, insisting on handling all communication with callers. Working with an event-driven receptionist forces workers to change their way of working. Rather than listening to a caller, the receptionist tells the worker what the caller said and which caller said it. If the worker needs to tell the caller something, that message is also routed through the receptionist. The worker tells the receptionist what to say, and to whom it needs to be said, and lets the receptionist do the work.
On the down side, this level of indirection can be a nuisance for the worker. Also, the worker needs to know how to deal with multiple simultaneous clients, since there is no guarantee the receptionist won't interleave incoming input. On the plus side, the worker never has to worry about a caller that is going to make him wait while the caller thinks, or about a caller that doesn't listen. Another plus side is that the worker doesn't have to know anything about how the communication actually takes place. All the worker talks to is the receptionist; it doesn't matter to the worker whether the receptionist and caller are communicating using a telephone, using fax, or even using smoke signals.
©Copyright 2000, Rogue Wave Software, Inc.
Contact Rogue Wave about documentation or support issues.