2. Status Server Overview

The Status Server serves as an open repository of status and state information available to any client within the CFHT network. Clients are able to view, create, update, remove or monitor information within the Status Server. In some respects, the Status Server could be thought of as a shared memory pool for multiple clients.

Some examples of how the Status Server is used include:

• A central staging area for the building of FITS files replacing template files. This allows FITS files to be built in a more parallel fashion without the need for explicit client-side synchronization.
• A replacement for the state information contained within passive text file databases (``par'' files. Information contained within ``par'' files require a relatively inefficient file scan from NFS mounted files.
• A source of information used in GUI status displayed and early warning systems.
• A source of instrument and session related information.
• A source of plant monitoring information.

2.1 Client $\Leftrightarrow$ Server Communication

The Status Server will listen over a socket interface to client requests. The server will service each request and send back an associated response. While it is possible to interact with the Status Server via a telnet session using its communications protocol, the Client C API is designed to abstract the complexity of the socket interface from the client program. The underlying communications mechanism between the client and server is based on TCP/IP socket communication.

2.2 Directory Structure

Objects within the Status Server are grouped together in a ``tree-like'' fashion patterned after the UNIX file system. As a result, it is possible for a client to traverse and manipulate objects within the Status Server much like traversing a directory tree and manipulating files in a file system. Objects within the Status Server can be referenced either via a fully qualified directory path/object name combination, or a relative path-name combination. In order to manage relative path references, a current path is maintained for each client connection. Rules to determine whether a path-name combination is expressed as an absolute path or relative path are applied the same way they are in a UNIX file system. A visual example of the type of structure used to hold Status Server information is shown in figure 1.

Figure 1: Status Server Hierarchical Name-Value Pair Representation

2.3 Directory and Data Object Information

Each directory and data object in the Status Server consists of a series of attributes. These attributes include:

1. Name - Within the Status Server the object name, in combination with its associated directory path location, must be unique. The name and directory path must consist of a string of 7 bit ASCII printable characters.
2. Value - The value stored with the object. The value of an object stored in the Status Server will always be enclosed within double quotes if it is valid. If the value of the object is not valid, it will not be enclosed within double quotes. For example, the following values would be considered valid: ``data'', ``0.0'', or ``sample data''. If a value is not enclosed within double quotes, it must always be one of the following values.
   1. NONEXISTENT - If a request is received by the Status Server to initiate a monitor on a data object which does exist, a data object will be created, and its value will be set to NONEXISTENT. For a client perspective, any request made to update or retrieve the value of this object will fail with an indication that the object does not exist, until the object is created with a ``touch'' command request (see section ).
   2. UNDEFINED - If a client has created an object, but has not assigned a value. This would be the initial value of an object following a ``touch'' command request (see section ).
   3. EXPIRED - If the object has not been updated within a ``lifetime'' length of time since its last update.
3. Comment - An entry describing what the object is.
4. Lifetime - Indicates the maximum amount of time this object can be considered valid. As an example, the current seeing may only be defined to be valid for an hour.
5. Auto-expire - Indicates that an object will be considered valid as long as the client connection to the Status Server is available. If the connection is broken, the value of the object will change to EXPIRED.

If a data object has a value of NONEXISTENT, it will be completely removed and deallocated whenever its use counts are zero. This means that a data object can not be completely removed if a client has performed a touch, monitor, or directory listing request on the object. This is a requirement to enforce pointer integrity within the Status Server.