|
Multicast beacon
|
|
The DAST multicast
beacon facilitates debugging of multicast connectivity problems. A
web based display of clients reporting to a given server shows the
connectivity between reporting clients. For examples, see the DAST web view and Grangenet web view.
The naive usage of the client includes a configuration file
(beacon.conf), in which all the required parameters are set. Normally
this is fine, for it allows the beacon to be run from the command line
with a simple:
/usr/bin/beacon
&
(or similar, depending where
the beacon application is installed)
A problem arises whenever multiple instances need to be run, since the
configuration file nominates only a single server. Additionally, local
"per server" directories need to be nominated to store local results
and the
configuration file lists only a single such directory.
The beacon
software from DAST.
The key to running multiple instances of the beacon client is to
realise that all the parameters in the configuration file may be
overridden by command line arguments. In fact, the configuration file
could be seen as a fallback mechanism to describe any parameters that
aren't
explicitly set at the command line. Thats good, for there are many
options which will generally remain the same for all instances; only a
few
options need to be different when running multiple instances.
To run beacons for both the DAST and Grangenet servers mentioned above,
you could run both instances with all the required parameters that are
different between the two servers (while the parameters in common are
still in the configuration file) e.g.
/usr/bin/beacon
--outputdir /home/beacon/outputfiles_dast --group
233.4.200.19 --centralservername
beaconserver.dast.nlanr.net &
/usr/bin/beacon
--outputdir /home/beacon/outputfiles_grangenet --group
233.70.142.1 --centralservername
beaconserver.grangenet.net &
In practice, all options for
either the DAST or Grangenet beacon could be in the configuration file.
For instance, if all the DAST options were in the configuration file,
then the local clients
could be run with something like:
/usr/bin/beacon
&
/usr/bin/beacon
--outputdir /home/beacon/outputfiles_grangenet --group
233.70.142.1 --centralservername
beaconserver.grangenet.net &
Alternatively, all the Grangenet options could be in the configuration
file and then running both would entail:
/usr/bin/beacon
&
usr/bin/beacon
--outputdir /home/beacon/outputfiles_dast --group
233.4.200.19 --centralservername beaconserver.dast.nlanr.net &
BTW, the beacon instances can be run in the background without the
"&" symbol at the end of each invocation line by enabling
backgrounding in the configuration file. Do this by uncommenting the
line
#BACKGROUND = 1
to become
BACKGROUND = 1
Lastly, the beacon(s) can be launched at boot time by a system
startup script, as below.
#!/bin/sh
#
# Start/stop/restart the multicast beacons
# Assume backgrounding has been enabled in configuration file
BEACON_HOME=/home/beacon/outputfiles
GRANGENET_HOME=/home/beacon/grangenet
beacon_start() {
# DAST beacon
#
cd ${BEACON_HOME} && /usr/bin/beacon
# Grangenet beacon
#
cd ${GRANGENET_HOME} && /usr/bin/beacon --outputdir
${GRANGENET_HOME} \
--group 233.70.142.1 --port 10002 \
--centralservername beaconserver.grangenet.net
}
beacon_stop() {
cd ${BEACON_HOME} && kill -HUP `cat multicastbeacon.PID`
cd ${GRANGENET_HOME} && kill -HUP `cat
multicastbeacon.PID`
}
beacon_restart() {
beacon_stop
sleep 1
beacon_start
}
case "$1" in
'start')
beacon_start
;;
'stop')
beacon_stop
;;
'restart')
beacon_restart
;;
*)
echo "usage $0 start|stop|restart"
esac
# End of beacon startup script
All comments and
suggestions about this page to Chris Willing <willing at
itee.uq.com.au>