Cliser: The C++ Server Hierarchy

A Server is a super-class for particular kinds of servers, categorized by threading. There are three choices: iterative (or single-threaded), Unix Fork (concurrent) or POSIX threads.

As subclasses of CommunicatorUser, Server and its subclasses inherit the send(), receive().

The primary responsibility of the subclasses of Server is to define interactWithClient() to provide some service to the client. In a POSIX Thread Concurrent Server, it is the responsiblity of a subclass of ServiceThread to define interactWithClient().

Servers (and clients) subclasses may use TCP or UDP protcols, and behave differently according to the protocol used:

• UDP provides fast, connection-less, although possibly unreliable commmunication.
• TCP provides slower, connection-oriented, reliable communication.

In an Iterative Server the same thread of execution accepts connections from clients and provides service for those clients. If the service being provided is time-consuming, then the queue of pending connections from waiting clients may become full, resulting in lost client connection requests.

In a Concurrent Server (POSIX Threads or Unix fork) one thread accepts connections and then passes the job on to a different thread. This requires more overhead than an Iterative Server, but the thread accepting connections is less likely to be busy since a time-consuming service will be performed by a different thread. Cliser's POSIX Thread Concurrent Server uses a ThreadPool to reduce the time-overhead associated with multithreading.

Cliser only supports concurrent servers for the TCP protocol. A server using TCP accepts connections on one communication endpoint and communicates with its client via a different endpoint. (This complexity is one of the details Cliser hides in its Communicator abstraction.) This means that in a multithreaded TCP server, one thread can listen for connections while another thread communicates with a client without conflicting, because the two threads are using different endpoints.

By contrast, a server using UDP uses the same communication endpoint for both receiving connections and communicating with the client. As a result, the multiple threads in a concurrent UDP server must share the same communication endpoint. Since a communication endpoint is a mutually exclusive resource, access to a shared endpoint must be synchronized (or a race condition will result), which eliminates most of the benefit of concurrent execution. However, you may always manually define a UDP Concurrent server.

Given this hierarchy, once a user specifies the parameters for their server via a Cliser user-interface, the Cliser code generator can simply generate a new class that extends the particular class whose name corresponds to the parameters specified by the user.