Cliser: The Java Server Hierarchy

Like a Client, a Server is a super-class for particular kinds of servers, categorized by protocol (TCP vs UDP) and threading (iterative or single-threaded vs. concurrent or multithreaded):

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

As with Client, the Server class serves as superclasses for TCP and UDP subclasses. The Server class defines a handle for a Communicator which it then initializes via an abstract initCommunicator() method. The primary responsibility of the subclasses of Client and Server is to define initCommunicator() to return an appropriate Communicator.

The Server subclasses behave differently according to the TCP/IP protocol the desired service is to use:

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

In an IterativeTCPServer 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 ConcurrentTCPServer one thread accepts connections and then passes the job on to a different thread (actually, a ServiceThread). This requires more overhead than an IterativeTCPServer, 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 ConcurrentTCPServer uses a ThreadManager 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.

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.