Park Project Report

Antonio Cauzo, Visara Urovi and Nikolaos Dipsis,

Supervised by: Kostas Stathis and Julian Dean
June 7, 2010

1
Contents
1 Introduction 4
1.1 Problem Description . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Aims and Objectives . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Architecture 5
2.1 Overview of GOLEM platform . . . . . . . . . . . . . . . . . . 6
2.2 Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Master and Monitor . . . . . . . . . . . . . . . . . . . . . . . 9

3 Interaction 10
3.1 Master-Monitor-Analyzer Interaction . . . . . . . . . . . . . . 11
3.2 Analyzer DCS update Interaction . . . . . . . . . . . . . . . . 11
3.3 Monitor-Analyzer DCS update Interaction . . . . . . . . . . . 13
3.4 Monitor-Analyzer NetDB update Interaction . . . . . . . . . . 13

4 Fail Over Mechanism 14

4.1 Analyzer Fail-Over . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Master-Monitor Fail-Over . . . . . . . . . . . . . . . . . . . . 17

5 Data representation 17
5.1 Default Communication Data . . . . . . . . . . . . . . . . . . 17
5.2 Network Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6 Implementation 20
6.1 Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2 Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3 Data Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.4 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

7 Installation 22
7.1 Minimal System Requirements . . . . . . . . . . . . . . . . . . 22
7.2 Installing Swipl and Nmap . . . . . . . . . . . . . . . . . . . . 23
7.3 Installing Raima DB . . . . . . . . . . . . . . . . . . . . . . . 23
7.4 Installing the application . . . . . . . . . . . . . . . . . . . . . 24

8 Conclusions and Future Work 24

2
List of Figures
1 An Overview of the system . . . . . . . . . . . . . . . . . . . . 6
2 Agents, Objects, Containers and Topologies . . . . . . . . . . . . 7
3 The Analyzer Architecture . . . . . . . . . . . . . . . . . . . . 9
4 The Master Architecture . . . . . . . . . . . . . . . . . . . . . 10
5 Overview of the Interaction Model . . . . . . . . . . . . . . . . 11
6 Master-Monitor-Analyzer Interaction Model . . . . . . . . . . 12
7 Agent-Object Interaction Model . . . . . . . . . . . . . . . . . 13
8 Monitor-Analyzer Agent-Object Interaction Model . . . . . . . 14
9 Monitor-Analyzer Agent-Object Interaction Model . . . . . . . 15
10 The Analyzer Model . . . . . . . . . . . . . . . . . . . . . . . 16
11 Analyzer Fail over . . . . . . . . . . . . . . . . . . . . . . . . . 17
12 The Master Model . . . . . . . . . . . . . . . . . . . . . . . . 18
13 Master Failover . . . . . . . . . . . . . . . . . . . . . . . . . . 19
14 Default Communication Structure DB . . . . . . . . . . . . . 20
15 Network DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3
1 Introduction
This Park project is funded by the Research and Enterprise Office at Royal
Holloway University of London. The project is a collaboration between
Dr. Kostas Stathis at the Computer Science Department and ThinkingSafe
company.
In this document we report the technical achievements of the project and
provide the necessary installation information. In particular we focus on the
architecture of the system and the designing choices.
In this project seek to collect and classify information about networks
and their devices. We use GOLEM (Generalized Onto-Logical Environment
for Multi-agent Systems), a multi-agent platform, to deploy a set of agents
which by interacting in a distributed setting, exchange network information.

1.1 Problem Description

Nowadays, most of the organizations rely on computers for performing their
business activities. Given an organization, it is common that we have multiple
devices interconnected in one or more networks. The common practice is that
there is no way to have an exact overview of the configuration of the devices
and networks in an organization, partly because networks and their devices
change in time or because they are too big or even in different locations to
have a complete information about them.
By collecting information on the devices, their status and the network
they belong to, the organization has a powerful tool to understand the
configuration of their networks and diagnose possible problems or week points.
We seek to realize an application which, once installed in some of the devices
of the network, we can collect information about a particular device. For
a device we would like to know what processes, services and applications
is running and additional hardware information such as operating system,
used space, memory etc. More importantly, we aim to construct a map of
the various networks and the devices that run on these networks. By doing
so, we can then monitor each network as well as diagnose problems or even
anticipate them.
In our previous work, we proposed GOLEM (Generalized Onto-Logical
Environment for Multi-agent system) [?, 2] which is a platform for developing
distributed multi-agent applications. Throw GOLEM we can model our
application as a distributed multi-agent system in which agents deployed
in various devices collect and exchange data in order to have a coherent view
of the networks and the devices.
The use of agents is justified by the need of combining reasoning capabilities

4
with the data collection mechanism. An agent is a autonomous software
entity that acts pro actively to solve a particular goal. We consider agents
that are situated in an environment.

1.2 Aims and Objectives

In this project we aim to demonstrate that GOLEM is a suitable solution for
practical real-time solutions where reasoning on a dynamic and distributed
environment is required.
To achieve this the specific objectives of our work are:
• Deploy a multi-agent system using GOLEM

• Implement data collection and monitoring functionalities

• Implement fail-over mechanisms so the system is able to self organize if

devices where the application is running is turned off or it disconnects
from the network.

• Test and validate the application

1.3 Organization
The document is structured as follows: In section 2 we give an overview of
the architecture of the system. In section 3 we describe in more detail how
the entities of the system interact with each other, and we provide the details
of the fail-over mechanisms. In section 5 we describe how we represent the
data in the data base. In section 6 we provide the implementation details. In
section 7 we illustrate how to install the system and the dependencies with
other software. Finally, in section 8 we conclude with a summary of the work
and possible future extension to this problem.

2 Architecture
The main goal in our system is to collect detailed information about a set
of networks and their devices. To achieve this we introduced three main
entities: Analyzer, Master and Monitor.
The Monitor’s main functionality is to collect information about a specific
device. In particular it actively collects information about the processes, the
hardware, the services running on a machine. The Masters functionality is to
control one network and to send this information to a data collector, namely
the Analyzer.

5
 The Analyzer interacts with Monitor agents to receive information about
devices, It also interacts with a Master agents to collect the information
about the network. The network information includes the IP address, MAC
address, Device type name and state. The analyzer can also detect to which
a device belongs.
The collected data is stored in a DB associated to the Analyzer. A user
can view these data by requesting them to the Analyzer. The Analyzer will
send the data and eventually the updates when they occur.

Printer
User Remote &
Local Local
Monitor Monitor

Analayzer A

Master & Local

Analayzer B Local Monitor
Printer Monitor
Local
Monitor Local
Monitor

Master & Remote & Analayzer D

Local Local
Monitor Monitor
Analayzer C

Printer
Local
Monitor Local
Local Printer Monitor
Monitor Local
Monitor

Master & Local

Local Monitor
Monitor
Master & Local
Local Monitor
Monitor

Figure 1: An Overview of the system

Figure 1 shows an overview of the system architecture. The figure represent

many local networks. In a local network we would install an analyzer in one
of the machines and an arbitrary number of Monitors. Monitors, can become
Master upon Analyzers request. The Analyzers can be installed separately
from Masters/Monitors and are organized in a default communication structure
which allows them to exchange the collected data and maintain copies of the
data-base. A user can connect to the system and request a view of the data.

2.1 Overview of GOLEM platform

The GOLEM agent infrastructure [3, 2, 1, 7, 4, 5] implements the concept of
agent environment [8].

6
 The GOLEM agent platform allows the deployment of three main entities:
agents, objects and containers. Agents are active and cognitive entities
that can interact with other agents and objects in the agent environment.
Agents are composed by a declarative mind, a component that supports
the reasoning abilities of the agent such as planning, decision making, and
temporal reasoning. The mind is situated in the agent environment via
another component that is called the agent body. This component contains
sensors for the agent to be able to perceive the environment and effectors
to be able to affect the environment. In other words, sensors and effectors
represent the interface between the agent environment and the agent mind.

Affordances

Agent
Physical action
Sensors Object

Emitter
Trigger
Effector

Speech
Act
Event

Intra Container Extra Container

   

Super/Sub Containers Adjacent Containers

Figure 2: Agents, Objects, Containers and Topologies

Unlike agents, objects are reactive entities. Objects have a trigger to

receive events from the environment and an emitter to produce reactions to
such events. The trigger and the emitter ensure that the interaction between
the object and the environment is completely asynchronous. An object is
composed by an external object which is connected to the trigger and the
emitter, and its purpose is to hide the complexity of an internal object,
which could represent an external resource. The general idea behind the
internal object is that it wraps in it a resource of the external environment,
thus hiding from the agents the complexity of interfacing with the external
resource. In other words the object abstraction can be a virtual entity or

7
a virtualisation of an external resource of the external real environment, for
example, a printer, a web service, or a database.
Central to the GOLEM agent platform is the concept of affordances:
normally this concept is taken to describe “all the action possibilities latent
in the environment, objectively measurable, and independent of an agent’s
ability to recognize those possibilities” [6].
GOLEM relies upon perceived affordances where entities of an environment
“suggest” to agents (whether artificial or human) how they should interact
with them. In other words the concept affordances in GOLEM represent the
external observable state of an agent or of an object as shown in Fig. 2(a).
Agents and objects are situated within containers. A container represents
a portion of the distributed agent environment and it works as a mediator
for the interaction taking place between agents and objects. Events describe
what happens in the agent environment as a result of actions being executed
by effectors. According to the happening of an event the agent environment
notifies those sensors capable of perceiving the action of the event. In
GOLEM three types of acts are embedded in an event: speech acts - to
allow agents to communicate with other agents and users; sensing acts - to
allow an agent to perceive the environment actively; and physical acts - to
allow the agent to interact with other entities, in particular objects, but also
agents as well. To simulate these acts GOLEM relies upon different kinds
of sensors and effectors the agent should possess in the agent environment.
Fig. 2(b) shows how the result of a physical act of an agent on an object is
perceived not only by the agent itself but also by another agent, using the
affordances of these entities within the container in which they are situated.
Containers provide the support for the mediation of the interaction in the
agent environment by means of the Ambient Event Calculus (AEC) [3]. The
AEC allows GOLEM to behave like a distributed agent environment where
the interaction between the entities (agents, objects, containers) is mediated
in the distributed settings, defining rules of interactions between the entities
involved. The AEC formalism also allows GOLEM to link containers between
each other in such a way that agents deployed across a network of containers
can move in the distributed agent environment.
Finally, GOLEM provides a Transportation Layer which transports the
exchanged messages from a container to another container.

2.2 Analyzer
The analyzer functionalities are realized in GOLEM by defining an Analyzer
Agent which exchanges actions within the environment. As shown in figure
3, a GOLEM container is deployed in a device and an Analyzer agent is

8
registered in the GOLEM container. Every Analyzer uses an analyzer object
for performing a set of procedures such as read and write information about
the networks in the data base, update or read the DCS etc.
Additionally, figure 3 shows an analyzer ack object which notifies to the
analyzer that a fail over mechanism is needed.

Analyzer Container

Analyzer procedure call Analyzer

Agent Object
return

no
tify
Analyzer
Ack Object

FAIL OVER

Transportation Layer

Figure 3: The Analyzer Architecture

As part of its functionality, an Analyzer decides what device running as

Monitors is ought to be the Master for the network (please note that inside
a network it is possible to have a master and many monitors). An analyzer
receives collects the network information from the master agent and collects
the device information from the Monitors of the network. Additionally, it
interacts with other analyzers in order to exchange the collected data, in this
way the data is replicated in many analyzers. In this way if we loose an
analyzer (i.e. due to connection problems) the system would not have data
loss. The details for this procedure are presented in section 3 and in section
??.

2.3 Master and Monitor

The Monitor and Master functionalities are realized in GOLEM by defining
a Monitor Agent which collects the data of the particular device where the
agent is running. As shown in figure 4, a GOLEM container is deployed
containing a Monitor Agent and a Master Agent. The Master Agent becomes
active only upon the Analyzer’s request. Both agent’s perform procedural
calls in a GOLEM object which can collect data from the network or can
collect specific device information.
Additionally, as with the Analyzer architecture presented in section 2.2,
figure 3 shows an ack object which notifies to the Monitor/Master that a fail

9
 Monitor Container

Monitor procedure call procedure call Master

Agent Object Agent
return return

no
tify tify
no

Monitor
Ack Object

FAIL OVER

Transportation Layer

Figure 4: The Master Architecture

over mechanism is needed.

In general. a Monitor has local capabilities to collect information about
a specific device. A Monitor can collect information about the devices in
a network (host-name, IP, mac address, state) and, for every device that is
not a monitor, its services; a local monitor can collect hardware (RAM, hard
disk, CD-ROM, microprocessors) and software data (OS,video driver), all
the processes running, all the installed applications and all the services.
A master can collect network data upon a request from an analyzer. In
particular, it will find the devices belonging to a network, their IP address,
MAC Address, device name and it can detect their state (up or down).

3 Interaction
In this section we explain more in detail how the entities we intrdiced in
section 2 interact to offer the functionalities of the system. In particular,
we explain how Analyzers interact with one another and how agents interact
with objects to update the data base and to detect failures in communicating
with the other agents. We also explain the interaction between the Analyzers
and the Master and Monitor agents in the network.
There are two types of interaction within the system: the first has to do
with the interactions between a GOLEM Agent and a GOLEM Object, and
the second is the interactions between agents.
In figure 5 we show how an agent relies on an object to perform a set of
procedures or to retrieve data or update the data base when such operations
are needed. We also show that agents interact with one another by sending
messages.

10
 Analyzer Container

Mediated vs direct communication

Agent Database

Object

Monitor Container

Agent Database

Object

Figure 5: Overview of the Interaction Model

3.1 Master-Monitor-Analyzer Interaction

A Master and a Monitor communicate data to the default analyzer by exchanging
a set of messages.
Figure 6 captures this interaction and illustrates how objects are used to
provide specific functionalities. When a Monitor and a Master are started,
the Master agent sents a hello message indicating the device where the agent
is running to the Analyzer. The analyzer, checks if it knows the device and if
knows the network where this device belongs. If the device is known, it has
a network and this means that this particular network already has a Master.
The Analyzer does reply which means that the Master agent will be inactive
unless the Analyzer request data from it. If the Analyeser does not know
the device, the Analyzer would request network data to the agent by using
a get network info message. In this case the Master actively collects network
data and sends them to the analyzer by using a network data message. To
collect the network data the Monitor Agent uses the Monitor Object. The
collected data are sent at first all the information acquired, then the Master
agent would sent to the Analyzer only changes to the current network.
When the Analyzer receives these data, it uses the Analyzer Object to
store the data into the DB.

3.2 Analyzer DCS update Interaction

In figure 7 we show the interaction between two analyzer agents and their
respective analyzer objects. In this interaction the analyzers will exchange
and update the information about the DCS.
In particular the figure 7 shows how two analyzer agents interact with

11
 Container (2) something new in network_data Analyzer
getInfo
add_master
getDB Analyzer
Analyzer Agent (2.1) Notify
update Object
messageReceived
Analyzer

(2.2) notify all the neighbour on. If

no ack is received, the Fail-over
(0) hello restarts
(2) network_data
(1) network_info

(0) hello (0.2) acknowledge

getInfo
getDevice
getProcesses Monitor
Monitor Agent
getServices Object
getHardware
message

(0.3) stop ||
(0.1) start Timer (0.4) Fail-over
Container

Figure 6: Master-Monitor-Analyzer Interaction Model

one another when an analyzer joins the network or when an analyzer is

notified that the father is down. In these cases, the analyzer sends a hello
message to its default father. When an analyzer receives a hello message from
another analyzer, it will update the DCS. In particular it will make use of
the update dsc() method of the Analyzer Object to store the new analyzer in
the DCS db as a child. Once the DCS has change the analyzer who updated
the dsc propagates the changes to every child and to its own father. The
propagation of the changes to the DCS are handled by the analyzer object
who creates a send updates event. These events are captured by the analyzer
objects in the containers where the send updates event was sent and they will
update their DCS (see update Database in fig. 7). The updates will be again
propagated to every child and father but not to the analyzer who sent them.
We also detect when a message fails to be acknowledged at a transportation
level. When this happens the fail over() method of the analyzer object is
called which updates the data base and sets updates to all the children and
the analyzer father. In case that a father is down a down event is created for

12
 «implementation class» «implementation class»
Analyzer Object Analyser Object
Database
{active} Analyzer Agent Analyser Agent {active} Database

hello
update_dcs()
update Database
send updates

container event

receive updates
update Database failOver()
progagate updates update Database
send updates
The updates are sent both to
the analyzer father and the down event
the analyzers children.
If a fail-over occured, instead DCS
of the father the update is sent
to the new father.

Figure 7: Agent-Object Interaction Model

all the analyzer childs. The fail over mechanism will be better explained in
section 4.

3.3 Monitor-Analyzer DCS update Interaction

In figure 8 we show the interaction between both the monitor object and agent
and both the analyzer anget and object. In this interaction the analyzer will
exchange and update the information about the DCS with the monitors (the
same is for the master) connected to him.
The pattern behaviour is the same explained above. As the monitor
belongs locally only to a particular analyzer, when it receives the message
alive from the monitor, it updates only its local database.

3.4 Monitor-Analyzer NetDB update Interaction

In figure 9 we show the interaction between both the monitor object and
agent and both the analyzer anget and object. In this interaction the analyzer
will exchange and update the information about the Net database with the
monitors and the masters connected to him as they collect all the network
data.
In particular the figure 9 shows how the interaction between the monitor-
master agent and their object, monitor-master agent-object and analyzer

13
 «implementation class» «implementation class»
Monitor Object Analyser Object
Monitor Agent Analyser Agent
Database
{active} {active} Database

alive

update_dcs()

update Database

All the db is sent.

receive updates

update Database

connection down

update Database

down event

DCS

Figure 8: Monitor-Analyzer Agent-Object Interaction Model

agent-object work. The interaction is both trhough procedure call (agent-

object: events inside the container) and message (either agent-agent or object-
object: events between differents containers). It is possible to notice how
the interactions between the different entities in the system either could
be mediated through the objects (agent-database) or it colud be a direct
interaction (agent-agent, object-object). Is also evident how the data collection
works. For instance, the networki nf o and the message requires certain
operation by the object to have the data to send available (getd evice, getp rocesses,
geth ardware, gets ervices) making the agent more simple for these particular
funtionality. In other words, it would be possible to define more complex
reasoning capabilities (for instance on the data collecetd) for the agents, in
order to achieve more complex behaviours.

4 Fail Over Mechanism

As we want a reliable system, in case the connection to an Analyzer is broken
we require the system to continue working without loss of data thus making
the w hole system a self-repairing system. More specifically, if a connection
to an Analyzer fails, for some reasons (link or nodes broken) the Analyeser,
Master or Monitor who is trying to connect to the failed Analyzer should to

14
 «implementation class» «implementation class» «implementation class»
Monitor Object Analyser Object Analyser Ack Object
Database
{active} Monitor Agent Master Agent Analyser Agent {active} {active} Database

return info return info

get_info
return info
alive
get_network_info
Device name, Ip, get_network
Mac, Status return netwotk info
network_info
update_ntw()
get_device_info insert & send updates
return netwotk info return done
device_info
update_ntw()
OS, Service Pack, insert & send updates
Owner, RAM, return done
CPU, HD, CD-Rom,
Services,Processes
update_net
insert & send updates
update_netData
insert & send updates

Net DB

Figure 9: Monitor-Analyzer Agent-Object Interaction Model

choose a different analyzer to communicate with.

In the system we can distinguish two different fails over: Monitor and
Analyzer Fail Over. The first involves Monitors/Master to Analyzer connection.
In case of a failure in the Analyzer who is collecting data from the Monitors/Master
of a network a fail-over mechanism would activate. In this case the monitors
choose a different analyzer accordingly with the well-known structure (Default
Communication Structure).
The second involves analyzer-to-analyzer connections. The information
collected by an Analyzer is replicated across the service grid. For this
reason it is very important to avoid data loss. In this case, if an analyzer
fails, the analyzer who was connected to it chooses a different Analyzer to
send the updates accordingly to the well-known list (Default Communication
Structure).

4.1 Analyzer Fail-Over

As part of the normal functioning, the Analyzer receives messages from
Monitor and Master Agents that inform the Analyzer about the network and
their devices or particular changes to the network. Figure 10 shows that,
for every message received, the Analyzer sends back an Acknowledgment

15
 When a message is received, an
acknowledge is sent either to the
Message from the Monitor (the
connected Master or to the
first will be the Master)
connected Analyzer

ANALYZER monitor interaction

ack

When an acknowledge is

A
received, the TimeCount Thread
associated with the sender is
stopped
receiver=true
When something change either
in the DCS or in the Network, an
update to the neighbour nodes
(Analyzer which this one is
connected to) is sent. The
TimeCount Thread is activated
update to check for the ack arrival.
Fail Over

analyzer interaction

If the ack is not received, the

Analyzer Object, inform the Hello or Update messages
Agent which is the node off and, received from Analyzers this one
according to the DCS, the father is connected to.
is notified.

Figure 10: The Analyzer Model

message. This helps the entity who sent the message to be sure that the
message was received successfully. For every message that the Analyzer sents,
a time counter is activated. If an ackowledgement is received before the due
time,the counter is stopped, and the connection is said to be working well.
However, if there is no acknowledgment and the time count exceeds the due
time, a fail over procedure is started.
Figure 11 shows how when an analyzer fails the default communication
structure is updated so that the analyzer who had as a father the failed
analyzer, connects to the grand father analyzer. To achieve this behavior, the
fail-over mechanism notifies the agent that its father is down. The analyzer
sents a hello to the grand-father which updates the DCS by adding the sender
as a child.

16
 Analyzer

Analyzer
ANALYZER Analyzer

FAIL-OVER

Analyzer Analyzer Analyzer Analyzer

Figure 11: Analyzer Fail over

4.2 Master-Monitor Fail-Over

Figure 12 shows
Figure 13 shows

5 Data representation
5.1 Default Communication Data
Figure 14 represents the structure of the information about the default communication
structure data. This data is stored in the database component of the featured
application and it purposefully illustrates the child-parent relationships between
the analyzers in the system. It is used for the communication among the
network nodes(analyzers) and for providing the necessary node localization
information to the featured application to perform its tasks. As we can see in
Figure 14, there is a generic type of a data structure containing the identifier
of an analyzer (node) along with entries for its state(up or down), children
and parents. Multiple instances of this generic type are stored and they could
be described a follows:

• Instance for child. Contains the node ID, its state and a child.

• Instance for child. Contains the node ID, its state and a parent.

17
 If the ack is not received, the
Ack from the Analyser
MONITOR
Monitor Object, according to the Fail Over
DCS stored in its database, will
choose the new Analyser to be
connected to. analyser interaction

When messages are sent to the

When a new Analyzer connect to
Analyzer, the TimeCount Thread
the network, the DCS change
is activated to check the correct

M
accordingly to its structure and
analyser’s behaviour.
this change is notified through
the parents of the node.
updateDCS
analyser interaction

ack

Figure 12: The Master Model

These instances are stored as entries in the database and they are linked
together by the node ID field. The complete description of an analyzer default
communication data is allowed by their collective information.

5.2 Network Data

Figure 15 represents the structure of the network information. It features a
generic type for data structures consisting of elements describing discovered
networked devices such as the device name, the operating system, its status
etc. (see Figure 15 ).
These elements denote the types of information collected from a device
along with the information for each of them that may be of variable size.
Instances of this data structure are stored in the database and they consist of
a Network Identifier to denote the network that the particular device belongs
to, the name of the device, a field for the type of a device element (operating
system, status etc.) and an array of strings for the information regarding the
particular type. These instances of device data types are stored as entries
in the database and they are linked together by the Network ID and Device
Name fields. The complete description of an analyzer default communication
data is allowed by their collective information.

18
 Analyzer

Analyzer

Analyzer Analyzer

MONITOR Master Monitor

FAIL-OVER
Printer

Remote & Local

Local Monitor
Monitor

Figure 13: Master Failover

19
 Node Children

PK AnalyzerID PK ChildrenID

Type State
NodeID FK1 AnalyzerID
State

Parents

PK ParentsID

State
FK1 AnalyzerID

Master Monitor

PK MasterID PK MonitorID

State State
FK1 AnalyzerID FK1 AnalyzerID

Figure 14: Default Communication Structure DB

6 Implementation
6.1 Analyzer
The analyzer is composed by three entities:
• the agent (prolog)

• the object (java)

• the ack object (java)

that live inside the analyzer container. The interaction between the prolog
and the java code is based on events emitted by the Golem lower levels
(Transportation Layer, Emitter, Effectors).

6.2 Monitor
The analyzer is composed by three entities:
• the monitor agent (prolog)

• the master agent (prolog)

• the object (java)

• the ack object (java)

that live inside the master-monitor container.

20
 Network CD Rom

PK NetID
PK Device ID Process
FK1 NetID
Name FK1 Device ID
IP Cd Rom : [MultiSet]
FK1 NetID
MAC FK1 Device ID
OS Processes : [MultiSet]
Processors Service
System Info
Owner
System Root
RAM FK1 NetID
HD DeviceID
Video Driver
Service Pack Seriveces : [MultiSet]

FK1 NetID
State DeviceID
HD : [MultiSet]

FK1 NetID
DeiviceID
Starte : [MultiSet]

Figure 15: Network DB

6.3 Data Base

The Data Base was implemented using the Raima Embedded (RDME) database
package and specification. Java access to the RDM Embedded (RDMe)
database is provided through a number of generated classes created by the
RDM Embedded ddlp database compiler. We create a RDME schema for the
two types of data needed for our application: the Default Communication
and the Network Data. When ddlp is given the JNI flag it will create a Java
source file for each record defined in the database definition schema. The
schema describes the functionality described in sections 5.1 and 5.2 (Figures
14 and 15 respectively).
The application will open the db database, add a new records( rec) of
both types of interest, update them, delete them and provide with numerous
filters for extracting meaningful information for the application. There are
two basic RDMe Java classes used to interact with the database engine. The
first is the RDMe Task class, the second is the RDMe Database class (refer
to RDME documentation) :
The Task class has member functions for all of the RDMe APIs that do
not actively access a database. The Database class has member functions for
all APIs that do access a database (add record, update record, delete record
and our filter functions). 6.4 User Interface
The application utilizes two user interfaces for the Default Communication
and the Network Data, both implemented in JAVA. The Default Communication

21
GUI acquires data from the Data Base through the custom DB filters and it
displays them using a JTree structure(see javax.swing). The Network data
uses similar filters to acquire data regarding all the devices in all networks
stored in the Data Base and it displays them using the JTABLE structure (see
javax.swing). The JTable structure is updated dynamically and it displays
all the types of elements described in 5.2 or a subset of them. The user
has an option of choosing this subset by pressing the names of the types in
a sub-interface that was implemented using the JList structure. Also, the
JTable features two buttons (Jbutton in javax.swing). The first triggers a
pop-up window that is again implemented using the JTable structure for
displaying information regarding all devices in a particular network. The
second button triggers a pop-up window that is as well implemented using the
JTable structure and it displays all the information the system has regarding
a particular device in a network.

6.4 User Interface

7 Installation
7.1 Minimal System Requirements
The system has been tested on several dual core computers, even if a single
core processor is enough. The operating system installed on this machine was
Windows XP: so the behaviour is tested only for this operating system. The
use of other operating system could affect the result of the data collected
since, for istance, nmap has different output depending on the operating
system on which is running on. Anyway, it is possible to change and, so,
to generalize the way the data are collected using an ad-hoc network data
collection system: in this way platform independent system could be easily
defined.
The minimum hardware requirements to make the system properly working
include:

• Pentium 233-megahertz (MHz) processor or faster (300 MHz is recommended)

• At least 64 megabytes (MB) of RAM (128 MB is recommended)

• At most 10 megabytes (MB) of available space on the hard disk

The software requirements to make the system properly working include these
installation:

22
 • Swipl offers a comprehensive Free Software Prolog environment, licensed
under the Lesser GNU Public License;

• Nmap (”Network Mapper”) is a free and open source (license) utility

for network exploration or security auditing;

• Java 1.4 or greater.

7.2 Installing Swipl and Nmap

To run the system both Swipl and Nmap are needed: the first represents
the agent mind and rules its behavour; the second is used to collect network
data information. For both is possible to find the documentation and the
download packages on line.

Swipl Here http://www.swi-prolog.org/pldoc/index.html it is possible to

find all the information about Swipl. In particular, the system has been
tested with the 5.4.7 version http://www.swi-prolog.org/download/old/bin/w32pl547.exe

Nmap At thi link http://nmap.org/book/install.html all the information

about the program can be easily accessed. Latest stable realease self-
installer (Windows platform) is available at http://nmap.org/dist/nmap-
5.21-setup.exe.

7.3 Installing Raima DB

The installation of RDM Embedded 7.x is all that is required to access the
RDM Embedded (RDME) database from the featured application. Once
installation is completed there are two simple configuration steps:

• Environment: There are two environmental settings that need to be

applied in order to access your data from Java: rdm embedded.jar file
needs to be in placed your CLASSPATH. The RDM Embedded library
files need to be in your path. The JNI interface requires rdm7, psp7 and
rdmejni. These will either be shared objects or dynamic link libraries
depending on your platform.

• RDME Command Prompt: Go to the Directory of the application

Type and run: ddlp -jni databaseName

23
7.4 Installing the application
After the installation of Swipl, Nmap, JVM and the database, it is enough
to put the jdk and the swipl bin folder in the PATH of the Environment
Variables (i.e. C : /P rogramF iles/Java/jdk1.6.01 8/bin; C : /P rogramF iles(x86)/pl/bin)
to have the application environment ready to run the application. par Now, it
will be enough to run the Analyzer.bat and the Monitor.bat in the preferred
configuration.

8 Conclusions and Future Work

We presented a monitoring problem in which we use a multi-agent application
for a flexible solution. We showed how, by using GOLEM we can have a
modular distributed architecture. We also have shown how we can achieve
the self-organization of the application.
As future extension, this project has many opportunities one of which is
to add sophisticated logic for the diagnostic of specific solutions of interest.
The modularity of the system allows for the application to be extended with
agents that can reason over specific data of interest.
In particular the system could be extendend:

• improving the system performances playing both with the agent mind
specification and the object functionalities;

• visualazing how the communication structure changes dinamically when

a fail-over scenario occurs;

• completing both the analyzer and the monitor entities in order to make
the system adaptable at many different fail-over occurences as a an
interesting case study.

References
[1] S. Bromuri, V. Urovi, P. Contreras, and K. Stathis. Virtual e-retailing
environment in golem. In Intelligent Environments (IE’08). IET, Jul
2008.

[2] Stefano Bromuri and Kostas Stathis. Situating Cognitive Agents in

GOLEM. In Engineering Environment-Mediated Multi-Agent Systems,
EEMMAS 2007, volume 5049/2008 of Lecture Notes in Computer Science,
pages 115–134. Springer, 2007.

24
[3] Stefano Bromuri and Kostas Stathis. Distributed Agent Environments
in the Ambient Event Calculus. In DEBS ’09: Proceedings of the third
international conference on Distributed event-based systems, New York,
NY, USA, 2009. ACM.

[4] Stefano Bromuri, Visara Urovi, and Kostas Stathis. Game-based E-

retailing in Golem Agent Environments. Journal of Pervasive and Mobile
Computing, 5(4), 2009. In press.

[5] Stefano Bromuri, Visara Urovi, and Kostas Stathis. iCampus: A

Connected Campus in the Ambient Event Calculus. International Journal
of Ambient Computing and Intelligence, 2(1):59–65, 2010.

[6] James J. Gibson. The Ecological Approach to Visual Perception.

Lawrence Erlbaum Associates, 1979.

[7] Kostas Stathis, Stella Kafetzoglou, Symeon Papavasilliou, and Stefano

Bromuri. Sensor Network Grids: Agent Environments combined with
QoS in Wireless SensorNetworks. In The Third International Conference
on Autonomic and Autonomous Systems (ICAS07), Jun 2007.

[8] Danny Weyns, Andrea Omicini, and James Odell. Environment as a

first class abstraction in multiagent systems. Autonomous Agents and
Multi-Agent Systems, 14(1):5–30, 2007.

25