1 |
ajm |
1.1 |
i-scream Protocols |
2 |
|
|
================== |
3 |
|
|
|
4 |
|
|
Contents |
5 |
|
|
-------- |
6 |
|
|
- Conventions |
7 |
|
|
|
8 |
|
|
- Host Connection Protocol |
9 |
|
|
- Host Heartbeat Protocol |
10 |
|
|
- Host Data Protocol |
11 |
|
|
|
12 |
|
|
- Client Control Protocol |
13 |
|
|
- Client Data Protocol |
14 |
|
|
|
15 |
|
|
Conventions |
16 |
|
|
----------- |
17 |
|
|
All protocols in this document assume a valid connection of |
18 |
|
|
the appropriate type has been made, and that data streams |
19 |
|
|
already available. All strings should and will be |
20 |
|
|
terminated with a \n (newline character) to indicate the end |
21 |
|
|
of the message. All messages are sent as ASCII Strings. |
22 |
|
|
|
23 |
|
|
Fixed protocol messages will appear in [] brackets, if there |
24 |
|
|
is a variety of options they will be seperated with the | |
25 |
|
|
character. For example: |
26 |
|
|
|
27 |
|
|
[OK|ERROR] |
28 |
|
|
|
29 |
|
|
Indicates that the message "OK" OR the message "ERROR" will |
30 |
|
|
be sent depending on the result of the last action. |
31 |
|
|
|
32 |
|
|
Data messages will appear in {} brackets, where the name in |
33 |
|
|
the brackets indicates the type (as in kind, not data type) |
34 |
|
|
of data that will be returned. For example: |
35 |
|
|
|
36 |
|
|
{lastmodified} |
37 |
|
|
|
38 |
|
|
Indicates that data indicating for use as last modified will |
39 |
|
|
be returned. |
40 |
|
|
|
41 |
|
|
If ever [ERROR] is sent back at any time, this indicates |
42 |
|
|
that all communication is over. EXCEPT where specified! |
43 |
|
|
|
44 |
|
|
Host Connection Protocol |
45 |
|
|
------------------------ |
46 |
|
|
The initial connection of a host to the i-scream server is |
47 |
|
|
through the FilterManager. A Host gets its configuration |
48 |
|
|
and then gets assigned a filter to connect to and start |
49 |
|
|
sending data. |
50 |
|
|
|
51 |
|
|
The port number of the filter manager is fully configurable, |
52 |
|
|
however the default at this time is 4567. |
53 |
|
|
|
54 |
|
|
Host (direction) Server Comment |
55 |
|
|
------------------------------------------------------------ |
56 |
|
|
[STARTCONFIG]----------> Requests to start |
57 |
|
|
receiving config |
58 |
|
|
information |
59 |
|
|
|
60 |
|
|
<---------- [OK|ERROR] If the server ok's |
61 |
|
|
the request or not |
62 |
|
|
|
63 |
|
|
[LASTMODIFIED]----------> Asks when the config |
64 |
|
|
was last modified |
65 |
|
|
(used when checking |
66 |
|
|
if the config has |
67 |
|
|
changed) |
68 |
|
|
|
69 |
|
|
<---------- [{lastmodified}Returns a long int |
70 |
|
|
|ERROR] time since epoc |
71 |
|
|
eg, 123456789 |
72 |
|
|
|
73 |
|
|
[FILELIST] ----------> Asks the server for |
74 |
|
|
the list of files |
75 |
|
|
that were used to |
76 |
|
|
build the config |
77 |
|
|
(used when checking |
78 |
|
|
if the config has |
79 |
|
|
changed) |
80 |
|
|
|
81 |
|
|
<---------- [{filelist} Returns a semi-colon |
82 |
|
|
|ERROR] seperated list of |
83 |
|
|
filenames |
84 |
|
|
eg, |
85 |
|
|
a.conf;b.conf;c.conf |
86 |
|
|
|
87 |
|
|
********** LOOP START ********** |
88 |
|
|
This loop reads configuration |
89 |
|
|
properties from the config |
90 |
|
|
|
91 |
|
|
[{property}] ----------> Sends the name of a |
92 |
|
|
property to be |
93 |
|
|
retrieved from the |
94 |
|
|
config file |
95 |
|
|
eg, UDPUpdateTime |
96 |
|
|
|
97 |
|
|
<---------- [{value}|ERROR]Returns the value of |
98 |
|
|
the requested config |
99 |
|
|
property |
100 |
|
|
eg, 120 |
101 |
|
|
If it is unable to |
102 |
|
|
find the requested |
103 |
|
|
property it returns |
104 |
|
|
ERROR to indicate |
105 |
|
|
that fact |
106 |
|
|
|
107 |
|
|
********** LOOP UNTIL ********** |
108 |
|
|
The loop continues until the host |
109 |
|
|
sends the following message |
110 |
|
|
|
111 |
|
|
[ENDCONFIG] ----------> Indicates that the |
112 |
|
|
host requires no |
113 |
|
|
more config |
114 |
|
|
|
115 |
|
|
********** LOOP END ********** |
116 |
|
|
Communication continues |
117 |
|
|
|
118 |
|
|
<---------- [OK] Indicates that the |
119 |
|
|
server is ready to |
120 |
|
|
proceed |
121 |
|
|
|
122 |
|
|
[FILTER] ----------> Asks the server to |
123 |
|
|
send it the host |
124 |
|
|
information of a |
125 |
|
|
filter that it |
126 |
|
|
should connect to |
127 |
|
|
|
128 |
|
|
<---------- {filter} Returns a semi-colon |
129 |
|
|
seperated list of |
130 |
|
|
FQDN hostname, UDP |
131 |
|
|
port number and TCP |
132 |
|
|
port number that a |
133 |
|
|
configured Filter is |
134 |
|
|
running on and |
135 |
|
|
assigned to the |
136 |
|
|
calling host |
137 |
|
|
eg, |
138 |
|
|
raptor.ukc.ac.uk; |
139 |
|
|
1234;5678 |
140 |
|
|
|
141 |
|
|
[END] ----------> Indicates to the |
142 |
|
|
server that the host |
143 |
|
|
has finished an will |
144 |
|
|
disconnect |
145 |
|
|
|
146 |
|
|
<---------- [OK|ERROR] Indicates that the |
147 |
|
|
server is either ok |
148 |
|
|
or that it thought |
149 |
|
|
there was an error |
150 |
|
|
|
151 |
|
|
Host Heartbeat Protocol |
152 |
|
|
----------------------- |
153 |
|
|
When a host is configured after it has connected it should |
154 |
|
|
obtain a property TCPUpdateTime. This indicates how often |
155 |
|
|
a host should send a "Heart Beat" which is a pro-active |
156 |
|
|
connection to the server by the host to indicate that it is |
157 |
|
|
still alive. This "Heart Beat" also allows a host to see |
158 |
|
|
its configuration has changed and act accordingly. In a |
159 |
|
|
well written host this should just be a case of dropping out |
160 |
|
|
of a loop and heading back to the start (connecting to the |
161 |
|
|
filter manager). |
162 |
|
|
|
163 |
|
|
Host (direction) Server Comment |
164 |
|
|
------------------------------------------------------------ |
165 |
|
|
[HEARTBEAT] ----------> Starts the |
166 |
|
|
heartbeat protocol |
167 |
|
|
off |
168 |
|
|
|
169 |
|
|
<---------- [OK|ERROR] Indicates that the |
170 |
|
|
server is ok or not |
171 |
|
|
|
172 |
|
|
[CONFIG] ----------> Indicates that the |
173 |
|
|
host wants to check |
174 |
|
|
its config |
175 |
|
|
|
176 |
|
|
<---------- [OK|ERROR] Indicates that the |
177 |
|
|
server is ok or not |
178 |
|
|
|
179 |
|
|
[{filelist}] ----------> Send a semi-colon |
180 |
|
|
seperated list of |
181 |
|
|
filenames |
182 |
|
|
eg, |
183 |
|
|
a.conf;b.conf;c.conf |
184 |
|
|
This should be |
185 |
|
|
identical to the one |
186 |
|
|
recieved in the |
187 |
|
|
connection protocol |
188 |
|
|
|
189 |
|
|
<---------- [OK] Indicates that the |
190 |
|
|
server is ok |
191 |
|
|
|
192 |
|
|
[{lastmodified}]----------> Returns a long int |
193 |
|
|
time since epoc |
194 |
|
|
eg, 123456789 |
195 |
|
|
This should be |
196 |
|
|
identical to the one |
197 |
|
|
recieved in the |
198 |
|
|
connection protocol |
199 |
|
|
|
200 |
|
|
<---------- [OK|ERROR] The server then |
201 |
|
|
checks all the files |
202 |
|
|
in the file list to |
203 |
|
|
see if they have |
204 |
|
|
been modified more |
205 |
|
|
recently than the |
206 |
|
|
lastmodified value |
207 |
|
|
if they HAVE that |
208 |
|
|
indicates that the |
209 |
|
|
configuration has |
210 |
|
|
changed and the host |
211 |
|
|
should re-configure, |
212 |
|
|
thus it sends ERROR. |
213 |
|
|
If the files remain |
214 |
|
|
unchanged the server |
215 |
|
|
will return OK to |
216 |
|
|
indicate the host |
217 |
|
|
should continue as |
218 |
|
|
before |
219 |
|
|
|
220 |
|
|
[ENDHEARTBEAT] ----------> Indicates to the |
221 |
|
|
server that the host |
222 |
|
|
has finished an will |
223 |
|
|
disconnect |
224 |
|
|
|
225 |
|
|
<---------- [OK|ERROR] Indicates that the |
226 |
|
|
server is either ok |
227 |
|
|
or that it thought |
228 |
|
|
there was an error |
229 |
|
|
|
230 |
|
|
Host Data Protocol |
231 |
|
|
------------------ |
232 |
|
|
The UDP data packets that are sent by the host contain |
233 |
|
|
simply XML data. For information on the format of this |
234 |
|
|
data see the XML via UDP specification document at: |
235 |
|
|
|
236 |
|
|
http://www.i-scream.org.uk/cgi-bin/docs.cgi?doc=specification/xml_via_udp.txt |
237 |
|
|
|
238 |
|
|
Client Control Protocol |
239 |
|
|
----------------------- |
240 |
|
|
|
241 |
|
|
<TODO> |
242 |
|
|
|
243 |
|
|
Client Data Protocol |
244 |
|
|
-------------------- |
245 |
|
|
|
246 |
|
|
<TODO> |
247 |
|
|
|
248 |
|
|
About |
249 |
|
|
----- |
250 |
|
|
This document was written by AJ Moore [ajm4@ukc.ac.uk] for |
251 |
|
|
use by the team working on a 3rd year Computer Science |
252 |
|
|
project called "i-scream". More details can be found on the |
253 |
|
|
project website; |
254 |
|
|
|
255 |
|
|
http://www.i-scream.org.uk |