--- projects/cms/documentation/specification/spec-realtime.txt	2000/10/30 16:49:16	1.1
+++ projects/cms/documentation/specification/spec-realtime.txt	2000/10/30 19:38:34	1.2
@@ -2,34 +2,109 @@ I-Scream Specification Outline (Realtime side only)
 ===================================================
 
 ajm4, 30/10/2000
+tdb1, 30/10/2000
 
 System Component Startup
-------------------------
+************************
 
 CORE
-****
+----
 
 
 Client Interface
-****************
+----------------
 
 
 Filter
-******
+------
+The filter is broken down into three main subcomponents. 
 
+  - Filter Manager
+      The Filter Manager is responsible for managing which 
+      filters are used by the hosts. The Filter Manager is 
+      available at a "well known" location which is pre-
+      programmed into the hosts. The Filter Manager is 
+      responsible for creating and managing the other 
+      components of the filter system.
+  
+  - Main Filter
+      The Main Filter is the single point that links back 
+      into the CORE of the system. It will connect to the 
+      DBI and the CLI to deliver data.
+  
+  - Filters
+      There can be multipler Filters, and these are the 
+      "front line" to the hosts. They all link back to the 
+      Main Filter to send data into the system. It is 
+      possible to run these Filters on any machine, allowing 
+      management of data flow.
+
+At startup a Filter Manager object is activated at the "well 
+known" location (probably a given machine name at a 
+predefined port). The Filter Manager will create an instance 
+of the Main Filter, and any Filters under it's control. 
+Through some mechanism the other Filters, elsewhere on the 
+network, will register with the Filter Manager. The 
+Filter Manager will need to tell each Filter the location 
+of the Main Filter upon registering. The Filter Manager will 
+then be in a position to receive connections from hosts and 
+pass them off to Filters.
+
 System Running State
---------------------
+********************
 
 CORE
-****
+----
 
 
 Client Interface
-****************
+----------------
 
 
 Filter
-******
+------
+When a host first loads up it knows where to locate the 
+Filter Manager because it's located at a "well known" 
+location. The host will fire up a TCP connection to the 
+Filter Manager to announce itself. The Filter Manager will 
+use some method (logically) to allocate a Filter to the 
+host. The Filter Manager should base this decision on 
+various factors, such as the load on the selection of 
+filters, and possibly the location in relation to the host. 
+The host will then be directed to this Filter for all 
+further communications.
 
+As the system runs the host will send data with (maybe) UDP 
+to the Filter (that it's been allocated to). This choice has 
+been made because it puts less onus on the host to make the 
+connection, rather the data is just sent out. However, to 
+ensure that the data isn't just disappearing into the depths 
+of the network a periodic heartbeat will occur (at a 
+predefined interval) over TCP to the Filter. This heartbeat 
+can be used as a form of two-way communication, ensuring 
+that everything is ok, and if required, to send any 
+information back to the host. This heartbeat must occur 
+otherwise the server may infer the host has died.
 
+This could link in to alerting. An amber alert could be 
+initiated for a host if the server stops receiving UDP 
+packets, but an red alert be raised if the heartbeat doesn't 
+occur.
 
+If, for some reason, the Filter were to disappear the host 
+should fall back on it's initial discovering mechanism - ie. 
+contacting the Filter Manager at it's "well known" location. 
+The host should report that it's lost it's Filter (so the 
+Filter Manager can investigate and remove from it's list of 
+Filters), and then the Filter Manager will reassign a new 
+Filter to the host. Communication can then continue.
+
+The idea of plugins to the Filters has been introduced. 
+These plugins will implement a predefined plugin interface, 
+and can be chained together at the Filter. Using the 
+interface we can easily add future plugins that can do 
+anything from parsing new data formats, to implementing 
+encryption algorithms. The Filter will pass incoming data to 
+each plugin in turn that it has available, and then finally 
+pass the data on to the Main Filter. The Filter need not 
+have any real knowledge about the content of the data.
\ No newline at end of file