| 13 |
|
|
| 14 |
|
Client Interface |
| 15 |
|
---------------- |
| 16 |
+ |
The Client Interface is essentially just one component with |
| 17 |
+ |
a series of lists within it. When run it should, obviously, |
| 18 |
+ |
create an instance of the Client Interface, and then bind |
| 19 |
+ |
this to the ORB and register with the naming service. It |
| 20 |
+ |
then needs to construct the "local clients". These clients |
| 21 |
+ |
communicate with the system using the same interface as the |
| 22 |
+ |
external clients, but they are tailored to specific |
| 23 |
+ |
purposes, such as E-Mail alerts, and SMS alerts. The Client |
| 24 |
+ |
Interface then listens on a "well known" address for clients |
| 25 |
+ |
to request a connection. |
| 26 |
|
|
| 17 |
– |
|
| 27 |
|
Filter |
| 28 |
|
------ |
| 29 |
|
The filter is broken down into three main subcomponents. |
| 51 |
|
At startup a Filter Manager object is activated at the "well |
| 52 |
|
known" location (probably a given machine name at a |
| 53 |
|
predefined port). The Filter Manager will create an instance |
| 54 |
< |
of the Main Filter, and any Filters under it's control. |
| 55 |
< |
Through some mechanism the other Filters, elsewhere on the |
| 56 |
< |
network, will register with the Filter Manager. The |
| 57 |
< |
Filter Manager will need to tell each Filter the location |
| 58 |
< |
of the Main Filter upon registering. The Filter Manager will |
| 59 |
< |
then be in a position to receive connections from hosts and |
| 60 |
< |
pass them off to Filters. |
| 54 |
> |
of the Main Filter, and any Filters under it's control. It |
| 55 |
> |
should also bind itself to the ORB and register with the |
| 56 |
> |
naming service. Through some mechanism the other Filters, |
| 57 |
> |
elsewhere on the network, will register with the Filter |
| 58 |
> |
Manager. The Filter Manager will need to tell each Filter |
| 59 |
> |
the location of the Main Filter upon registering. The Filter |
| 60 |
> |
Manager will then be in a position to receive connections |
| 61 |
> |
from hosts and pass them off to Filters. |
| 62 |
|
|
| 63 |
|
System Running State |
| 64 |
|
******************** |
| 69 |
|
|
| 70 |
|
Client Interface |
| 71 |
|
---------------- |
| 72 |
+ |
In the running state the Client Interface is always |
| 73 |
+ |
listening for clients on the "well known" address. When a |
| 74 |
+ |
connection is received it is passed in to the main Client |
| 75 |
+ |
Interface and the client is queried about which hosts it |
| 76 |
+ |
wishes to receive information about. This is then stored in |
| 77 |
+ |
an internal "routing table" so the Client Interface knows |
| 78 |
+ |
which hosts to send the information on to. This routing |
| 79 |
+ |
table is constructed with this form; |
| 80 |
|
|
| 81 |
+ |
host1: client1 client2 client5 |
| 82 |
+ |
host2: client2 |
| 83 |
+ |
host3: client3 client4 |
| 84 |
+ |
host4: client1 client3 |
| 85 |
+ |
|
| 86 |
+ |
This design is such that when a piece of information is |
| 87 |
+ |
recieved from a host the Client Interface can immediately |
| 88 |
+ |
see which clients wish to receive this data, without too |
| 89 |
+ |
much searching. |
| 90 |
+ |
|
| 91 |
+ |
The "local clients" function just like any other client, |
| 92 |
+ |
although they are local, in that they will wish to receive |
| 93 |
+ |
information about hosts they are interested in. However, |
| 94 |
+ |
they will contain a lot more logic, and be required to work |
| 95 |
+ |
out who wants to be alerted about what, and when. They will |
| 96 |
+ |
also be responsible for sending the alert. |
| 97 |
|
|
| 98 |
|
Filter |
| 99 |
|
------ |
