Some Background and Current Challenges

Backgound on the Spaceroom Tools and Architecture

The Spaceroom application system is developed in Delphi. (Delphi is an OO Pascal based development environment that is heavily component based). One suite of components that is included with the package is an Open Source Internet set of components called Indy. The Indy components provide both Client and Server components for many different protocols including SMTP, HTTP and FTP. This allows a developer to very quickly create applications that can have both client and server capabilities. There server components are multi-threaded and very solid.

The Spaceroom system is composed of a number of applications that work together. From the users end is the SRConsole application which is a plugin based program designed to provide views of key information related to the operation of the ship. The visibility of the various screens are based on user role definitions such as Navigator, Helm, Communications, Tactical( weapons and defense), and Engineering. The Console app also provides interactive controls to adjust the function of the ship, (for example Throttle control).

There is also a SRModel application that represents the functions of the ship. It generates the data that is displayed on the consoles as well as accepts input from the controls.

There is an application called USBWatch which scans for a registration file in a directory on a USB drive. If it finds it is connects to a local running instance of the console and “logs in” the user to which causes the Console to autoconfigure the screens to the roles defined for the user.

Currently configuration information is stored in XML files.

Communication Challenges

Later I will go into detail about the model design architecture (and the heavy use of interfaces). The model is actually working fairly well. A timer is used to drive the event system which triggers the generation of power, and then the use of the power by the ship’s components (eg. engine, shields, etc). At the end of timer cycle the program iterates on a list of registered clients and sends a copy of the updates to each.

The current challenge is that the client is receiving a valid XML packet of data for display, but then a copy is received that seems to be escaped and causes the XML parser to fail.

Debugging is an interesting challenge as well since each application hosts an HTTP server component set to port 80. This means only one of the programs can run on a machine at a time. (It is another digression about the rationale related to using standard HTTP for the various programs which will come later).

One option is to change the push model from the server to a pull model from the clients. The advantage of the push model is that all consoles are updated at the same time (roughly) and the server can time the delivery at the end of the computation cycle. In a pull model, the clients would not be synchronized and would have to wait until the server was finished with its computation cycle. With 4-5 clients polling it seems an inefficient method.