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