ࡱ > \ ^ [ 7 t bjbjUU 4R 7| 7| n l * * * 8 b $ - 6 : : : : : 4 , , , , , , , $ . 50 D , 8 @ 8 8 , $ : : , $ $ $ 8 : : , $ 8 , $ $ ' )
* : * < * "! )
* , 0 - ) , y1 " y1
* $
TITLE \* MERGEFORMAT Host to Filter protocol (XML)
SUBJECT \* MERGEFORMAT Recommendations for the Host to Filter protocol
This document covers some of the suggested recommendations for laying out data in XML to be sent from a host to a filter.
Revision History
07/03/01Initial creationCommitted by:pjm2Verified by:tdb1Date:24/03/01Committed by:Verified by:Date:Committed by:Verified by:Date:Committed by:Verified by:Date:Committed by:Verified by:Date:
TOC \o "2-9" \h \z \t "Heading 1,1,Heading 5,5,Heading 6,6,Heading 7,7,Heading 8,8,Heading 9,9"
HYPERLINK \l "_Toc510031973" Introduction PAGEREF _Toc510031973 \h 2
HYPERLINK \l "_Toc510031974" Background PAGEREF _Toc510031974 \h 2
HYPERLINK \l "_Toc510031975" Specification PAGEREF _Toc510031975 \h 2
HYPERLINK \l "_Toc510031976" Flexibility and minimising bandwidth PAGEREF _Toc510031976 \h 3
Introduction
This document shall help to provide a separate party with the knowledge required to use their own implementation of a piece of host monitoring software. In particular, this document details the expected manner of data transfer from a host to the central server via a filter.
Background
Hosts are expected to periodically send UDP packets to the central monitoring system. Such packets may contain various pieces of information about the host, such as how much free memory is remaining on the host, etc.
Specification
It is the responsibility of the host monitoring software to realise where to send its data, by means of some auto-configuration system, or otherwise.
Each discrete bundle of data from the host must be sent via a UDP packet to the central monitoring system. There is no limit to the size of this packet, however, the server may
reject packets that are too large. The central monitoring system may ignore any data after the first 8kb of each packet, resulting in the possibility of such packets being rejected due to malformed/incomplete contents.
The UDP packet must contain a complete and well-formed piece of XML mark-up, describing the data that the host is submitting.
The XML contents of the UDP packet may define a document encoding standard, however, this is not a necessity as a default encoding can be assumed, this being suitable in most cases.
Any packets that do not parse as being valid XML shall be rejected by the server. This is likely to also include any packets that have the closing root tag placed after 8kb from the start of the packet's contents.
The XML markup within a packet is typically used to specify the data that the host is submitting. This must consist of at least a root tag, called "packet".
For example, the bare minimum that a host should send is the following: -
Note that every XML tag must also have a matching closing tag.
The server can recognise parameter values within tags, such as: -
Data to be transmitted may be defined within the parameters of tags (as above) or it may be defined within its own tags, vis: -
raptor
aaa.bbb.ccc.ddd
To avoid confusion, it is clearly necessary to escape any characters that may be incorrectly misinterpreted as XML by the parser.
The XML structure may be free-form. Any leading and trailing spaces are ignored in values. For example, the following defines exactly the same data as the above example: -
raptor
aaa.bbb.ccc.ddd
In cases where multiple data may be present, it may be more useful to nest tags to a number of levels. For example: -
raptor
aaa.bbb.ccc.ddd
23677
23534
10390
Such formatting is perfectly acceptable by the server. Packets may also contain comments, for example: -
raptor
aaa.bbb.ccc.ddd
23677
23534
10390
Remember that malformed XML data would be rejected by the central monitoring system without acting upon it. Thus, we urge would-be host developers to take care.
Flexibility and minimising bandwidth
The means of submitting host data via UDP containing XML markup is provided so that future customisation is easily possible. It would be possible to easily tailor a custom piece of host monitoring software to provide exactly what data is desired for adequate monitoring.
Some of the XML markup demonstrated above contains a lot of rendundant features. For example, it is not necessary to lay the contents out neatly (although this certainly helps visualise the contents).
The amount of data sent within each UDP packet may be (in some cases, vastly) reduced by using some of the ideas described below: -
Remove unnecessary linefeeds and 'white space'
If a single piece of data is to be represented, it will usually occupy less space if it is stored as an attribute to a tag, rather than within a pair of tags.
Comments within the XML may be useful for testing purposes, however, the server ignores all comments so these can be removed to reduce packet sizes.
Taking the above into account, this means that the final XML example above may be turned into the following without losing any information: -
236772353410390
Notice how all unnecessary 'white space' and linefeeds have been removed. The comment has also been removed. Values such as "machine_name" and "ip" have both been stored as an attribute of the root node ("packet") as this results in a smaller packet size.
The i-scream Project
SUBJECT \* MERGEFORMAT Recommendations for the host to filter protocol
PAGE 4
PAGE 3
i-scream The future is bright; the future is blue.
The i-scream Project
University of Kent at Canterbury
http://www.i-scream.org.uk
7 8 9 : S T i j ! # $ ݇ &j >*B*UmH nH ph u CJ OJ QJ mH nH uj} UmH nH u j UmH nH umH nH u &j >*B*UmH nH ph u 0J mH nH uj 0J UmH nH u mH nH u j U^J / 9 - . / 0 { r $$If a$ l $$If l 4 0 8 0 6 4
l a $If $a$
9r
n s 0 > C P U V W 9L $$If l ֈ 84 8
0 6 4
l a $If $$If a$ W X Y _ h i j k L F $If $$If l r 84 8
0 6 4
l a $If $$If a$ k l m n | } $$If a$ $If l $$If l 4 0 8 0 6 4
l a H, B 9 B 9 B $$If a$ $If $$If l ֈ 84 8
0 6 4
l a [ U U $If $$If l r 84 8
0 6 4
l a $$If a$ $If l $$If l 4 0 8 0 6 4
l a H, B 9 B 9 B $$If a$ $If $$If l ֈ 84 8
0 6 4
l a [ U U $If $$If l r 84 8
0 6 4
l a $$If a$ $If l $$If l 4 0 8 0 6 4
l a H, B 9 B 9 B $$If a$ $If $$If l ֈ 84 8
0 6 4
l a [ U U $If $$If l r 84 8
0 6 4
l a $$If a$ $If l $$If l 4 0 8 0 6 4
l a H, B 9 B 9 B $$If a$ $If $$If l ֈ 84 8
0 6 4
l a ! " # s [ Y S M G G G S
n
n
9r $$If l r 84 8
0 6 4
l a ! " # $ % A B C D Q R S m n o p q r s t u ѽѽޕѽѽsn j Ujk UmH nH u &j >*B*UmH nH ph u jq UmH nH u &j >*B*UmH nH ph u mH nH u0J mH nH uCJ OJ QJ mH nH uj 0J UmH nH u mH nH u j UmH nH ujw UmH nH u(
? Q
R
) * ! / 0 ! % / { # ' j k CJ ^J ^J 56CJ4 \]^J 56B*CJ4 \]^J ph 5j 56B*CJ4 U\]^J mH nH ph sH umH nH sH umH sH j UmH sH 0J mH nH u0J
j 0J U j U0J OJ QJ ^J 10 o p z { f g # : M e r " # # 0 \ } > a J K L M r s s N O 7 8 5 k l n $a$ $a$
&