|
|
Originally created on January 27, 1999
First and foremost, a digression into the origins of this software... I have been curious about how internet web servers worked, both the HTTP protocol, and implementation of the services. Over the long holiday weekend in November 1998, I decided to write my own server as a learning experience. Once I had the basics of serving static pages working, I decided to see how difficult it would be to integrate the server with the PICS data system. If successful, this integration would allow my server to generate reports using live PICS data on demand. I confess to an ulterior motive here... if the software were to be accepted by FPC, it would relieve me of the tasks of rendering reports to printers and displays at the end-user's desktops – a task I was not looking forward to performing. On the other hand, this approach does offer a very well understood interface for anyone who has "surfed the net."
My original intent was to keep the software as modular as possible, in case I needed to break out some of the tasks into separate applications and to make it easier to integrate existing applications as modules of this package. With a few exceptions, I think I succeeded. The bulk of the server itself resides in the HTTP.C module, most of the other modules (other than MAIN.C) render a specific type of report. The EMITTERS.C and SUMMARY.C modules contain common code for rendering the various summary reports and use a caller-defined filter function to determine which points to include in the report.
The project still includes a few modules that are still undeveloped (and their entry points are not called). SCHED.C contains a skeleton of one possible scheduler system that I might integrate into the package. SMTP.C contains clones of many of the PEMA functions. I was anticipating using the e-mail (SMTP) capability to send scheduled reports to users. TRIGGERS.C is an empty module where I plan to add code for defining, testing, and firing triggers of various types. The triggers are a companion to the scheduler so that event may be scheduled to fire based on time (scheduled) or some kind of event (triggered).
The PICS Report Generator (PicsRPG) is a multi-threaded server application that registers with the PICS Task Monitoring agent as CAT_WEB. For reporting functionality, there will be no difference between the primary and backup PicsRPG servers. For any data input and/or control functions that may be created, only the primary PicsRPG server will accept and process these commands. The backup server will redirect the user's browser to the primary whenever this type of page is requested.
Here's an overview of how the server is designed:
PICS Report Generator Design
This is where the WinMain (Windows application entry point) procedure lives, along with all of the main program window support code. Basic initialization functions are performed in the module during the startup phase. Then the program's windows and threads are created. This module is responsible for maintaining the PICS Task Monitoring interface and all related PICS interface tasks.
This module provides functions create (and destroy) a subscription to all PICS real time data. It also provides a function to store the real time data in a local memory structure for use in reports. When the trigger functionality is added, this module will also call any trigger test functions associated with real time data points as they are received.
The startup code for this thread loads the web server's configuration data and builds a table of known report services. Then the server's TCP listen socket is created and activated. Whenever an incoming connection request is detected, a client thread is spawned to handle it. If all client thread resources are in use, then this thread will accept the connection and respond with a "Server Busy" message, indicating that the user should resubmit the request. (NOTE: We could put a quick expiration in the HTML header allowing the browser to automatically resubmit the request, too.)
Users will be able to schedule themselves to receive e-mail reports at specific times (or when specific event occur). Administrators will also be able to schedule other things like standard report generation.
Various system events will be able to trigger report generation and/or e-mail. Most events will be related to real time data, but other possibilities include things like Task Monitor messages announcing subsystem status changes. That might be desirable because not all subsystems will have points in the real time data stream (think: non-critical nodes).
This will be similar to (or perhaps a complete replacement for) the PICS E-Mail Agent (PEMA). Messages and report files may be queued for delivery (and possibly later deletion) to a list of e-mail addresses.
Each client thread is created to handle a single URL request. After the request has been served, the thread closes the TCP connection and terminates.
After breaking an incoming HTTP protocol request into its component parts, the client thread will pass the URL to the HTTP URL Get module for further processing (under the thread's context).
Each of the pre-defined reports has an associated service module. Some modules provide a number of very similar reports by using slightly different filtering functions to select points for the report.
|
|