Daemon

The daemon package contains classes that serve the needs of clients.

Inheritance

Figure 1. Inheritance in the Daemon Package

Daemon
Daemon unifies all of its children by extending Thread and containing any static variables to be shared by all daemons.
AcceptDaemon
The first major division of daemons separates AcceptDaemons from DedicatedDaemons. An AcceptDaemon listens to a ServerSocket waiting for a connection; at the moment of contact, the AcceptDaemon takes some defined action then resumes accepting connections (or terminates if appropriate).
DedicatedDaemon
The other major kind of daemon in the project, besides AcceptDaemon, is DedicatedDaemon. Instead of spending its time waiting for connections, a DedicatedDaemon is created and initialized with a single connection, which it serves for the duration of its existence.
UniversityAcceptDaemon
The project is available to the public when the UniversityAcceptDaemon (or UAD) is started, because the UAD directly or indirectly starts all other threads for the project. The UAD listens to a designated port and accepts client connections, immediately passing them to an AuthenticateDaemon.
AuthenticateDaemon
An AuthenticateDaemon is a kind of DedicatedDaemon that registers a client and validates it in the authentication database. Once a client is validated for a certain role, the AuthenticateDaemon starts an appropriate dedicated session daemon to serve that client.
DedicatedSessionDaemon
DedicatedSessionDaemon is the parent of all daemons that directly serve client's requests.

Dedicated Session Daemons

"Dedicated session daemon" is a descriptive term for all daemons that directly serve client's requests; the "dedicated" implies a one-to-one correspondence between client and daemon, and the "session" implies an established connection that involves requests and actions. This term is more generic than the class name of the parent of all dedicated session daemons--that is, DedicatedSessionDaemon--so the two should not be confused. Three words, separated by spaces and usually lowercase, together refer to the category of daemons; a squished word, without spaces, refers to the single class.

Dedicated session daemons, or DSD's, do most of the "moving and shaking" in the client/server communication world. The parent of all DSD's, DedicatedSessionDaemon, sets up a framework of request handling that all the children follow. In addition, the very structure of the DSD inheritance determines security for the project.

Request Handling

DedicatedSessionDaemon extends DedicatedDaemon, which means that all DSD's are created and initialized with a single client connection. The run() method in DedicatedSessionDaemon starts a loop which first listens for a Request from the client and then attempts to serve it, in a method called handleRequest().

Each child of DedicatedSessionDaemon overrides the handleRequest() method to serve requests. A TakerDSD, for instance, overrides handleRequest() to serve all requests dealing with the test taking process (like GET_NEXT_QUESTION_REQ and REGISTER_ANSWER_REQ). If a DSD cannot service a particular request, it passes the request to its parent's handleRequest() method. This fact of chained request handling makes the inheritance structure very important to security; if a certain DSD is derived from TakerDSD, for example, it will then be capable of handling all the requests of a TakerDSD plus any more itemized in its own handleRequest() method.

Structure of Inheritance

A client who registers as a test Taker is connected to a TakerDSD; a test Creator to a CreatorDSD; and an Administrator to a AdminDSD. These three Roles, then, correspond to different security levels based on the ancestry of their daemon.

TakerDSD derives directly from DedicatedSessionDaemon and handles all requests pertaining to the test taking process. Currently, all the other DSD's extend TakerDSD, so that all the roles are allowed to take tests.

CreatorDSD and AdminDSD are both more priveleged than TakerDSD, in some different ways but also in some similar ways. Since they share some functionality, they both inherit from ManipulatorDSD, which can handle requests for information about the university--information that both creators and administrators need to have. CreatorDSD then handles requests pertaining to test editing and offering, whereas AdminDSD contains functionality for authentication and database administration.

DedicatedSessionDaemon, itself, does not serve any requests except for TERMINATE_REQ (to signify an end of session). If a DedicatedSessionDaemon's handleRequest ever gets a request other than TERMINATE_REQ, it knows there has been a security breach.


If that is not clear, take the following example: Mary is authorized to be a taker, and so is connected to a TakerDSD. However, she invents a way to make her client program send an EDIT_TEST_REQ--a Request allowed only to test creators. The request is given to TakerDSD's handleRequest() method, but since TakerDSD cannot serve the request, it is passed to TakerDSD's parent (DedicatedSessionDaemon). DedicatedSessionDaemon realizes that the client wanted a Request that her daemon was not equipped to handle, which means a security violation.

Making Your Own Dedicated Session Daemon

PITA was created with three Roles, but if you want to expand PITA with different Roles to serve different Requests, you can by adding files to the daemon package (and modifying one file in the communicate package). Perhaps a new Role could be Teacher's Asssistant--neither merely a Taker nor as much as a Creator.

Choose a place to join the inheritance tree, and then create a class for your DSD. Override handleRequest()--and if you want to, initializeAction(), acceptAction(), receiveAction(), terminateAction(), and deug()--and you are ready to go. If you need to make new Requests, add them to the Request class (in Request.java in the communicate package). See CreatorDSD.java as an example of a straightforward DSD implementation.

Maintenance Daemon

The Maintenance daemon is a special kind of DSD that isn't a dedicated session daemon at all. It derives from DedicatedSessionDaemon only so that it can access some shared variables; it is started automatically by UniversityAcceptDaemon and is associated with no client.

Maintenance daemon has a list of time-stamped tasks which it performs at the appropriate times. Its duties include automatic starting/ending of tests and shutdown of inactive clients.


Table of Contents
Joel C. Adams (adams@calvin.edu)
Karl Voskuil (kvosku94@calvin.edu)
November 1997 Calvin College