4 Data Acquisition Methods
There are currently two ways of acquiring data from the Beam Division:
by polling and by setting up a callback. In polling mode an
XML-RPC client simply sends a list of device names to the server and
the response contains a corresponding list of their values. In
callback mode a client gives the Beams Division's XML-RPC
server a device to monitor for some state change (which could be a
periodic timer), a list of devices to collect data from and finally a
URL and method of an XML-RPC listener (a "client server") which is
called in order to return the values when the given device's state
changes.
It is expected that a mix of these two methods are needed. The
callback method is used to collect in-spill data while the other
method is used to get out-of-spill (ie. pedestal) data by polling some
settable time after the callback is called.
[requirement]:Ability to use polling and callback access methods.
[requirement]:Ability to configure separately in and out of spill
devices to monitor.
[requirement]:Ability to configure inter and intra timing for
out-of-spill data collection.
[requirement]:Independence from near and far detector running. This
process should run irrespective of any other data acquisition.
4.1 A Note on Security
There is no inherent security in the XML-RPC protocol. Data is passed
over the wire in plain text. Also, anyone who can reach the server's
port can execute the remote procedure calls. Of course, the XML-RPC
server is free to implement some kind of authentication, but the
stateless nature coupled with the plain text transfer, makes this
difficult. Also, security developed in an ad-hoc fashion would only
by pure luck or accident be reliable.
In the case of the Beams Division server, all remote procedure calls
are ``read only'' in the sense that they only return data and do not
allow for any control. So, at worse, this server is vulnerable to a
denial of service attack.
In the case of the callback listener described above, there is the
potential for data corruption if a malicious process connects to the
listener and inserts false data.
It is likely that TCP
Wrappers5 will be usable
to satisfy this. [fixme]:TCP wrappers are usually used via the tcpd
daemon which inserts itself between inetd and the daemon to
executed. Instead of inetd directly starting the daemon it starts
tcpd which checks the connection against hosts.deny and hosts.allow
configuration files. Only if the connection is valid is the actual
daemon started. However, in the case at hand, the XML-RPC listener
will be contacted at a rate on order of 1/2 Hz. This use may be too
CPU intensive, add problematic timing delays and cause problems in
writing the output ROOT file. In any case the following shall be
satisfied:
[requirement]:Sufficient security must be in place to assure the
integrity of the data and invulnerability to denial of service
attacks.