Configuring a Mobile Agent System
Created by Tony White
This web page provides details on configuring a Mobile Agent System
(MAS) using the Mobile Code Toolkit v1.6.2. This version of the toolkit
relies heavily upon java RMI. A running MAS consists of a set of mobile
code daemons running on one or more java-enabled devices with logical migration
pathways defined between them. Each mobile code daemon is run using the
command:
java [-classpath path] mct.RMINetletDaemon properties-file
The -classpath command line argument is optional. If omitted, the java
interpreter will use the value of the CLASSPATH environment variable. The
properties-file is an ASCII file stored in the local file system that can
be read by the mobile code daemon and contains "variable=value" statements
that can be parsed by the load(java.io.InputStream) method of the java.util.Properties
class. The variables that can be used are defined here.
From the point of view of configuring a MAS, migration pathways must
be configured and it recommended that they form a ring in order that using
default migration for an agent will ensure that the agent ultimately traverses
all devices in the MAS. Migration pathways are set up by pointing the migration
facilitator of one mobile code daemon at the migration facilitator of another
mobile code daemon. The migration
facilitator and RMI migration
sections of the mobile code daemon properties file are, therefore, linked.
The mediator is run using the command:
java [-classpath path] mct.mediator.RemoteMediator mediator-properties-file
The -classpath command line argument is optional. If omitted, the java
interpreter will use the value of the CLASSPATH environment variable. The
mediator-properties-file is an ASCII file stored in the local file system
that can be read by the mobile code daemon and contains "variable=value"
statements that can be parsed by the load(java.io.InputStream) method of
the java.util.Properties class. The variables that can be used are defined
here.
It is important to note that the RMI registry (rmiregistry) must be
running on each device for the MAS to function correctly. The rmiregistry
process is not shown in the two figures below.
Consider three mobile code daemons, linked as shown in the figure below. 
In
this example, three daemons are running in three separate java virtual
machines (JVMs), the ovals representing the daemons with id's ND01, ND02
and ND03. Each mobile code daemon has a single migration facilty running,
MF01, MF02 and MF03 respectively, and a communication facilitator CF01,
CF02, and CF03. The full identifiers associated with these pieces of mobile
code have not been included for reasons of clarity. A fourth JVM is running
the mediator; the region-wide mobile agent location directory. The lines
with arrows in the above figure represent the default migration paths.
Assuming that the three mobile code daemons run on devices named host01,
host02 and host03 respectively, with no startup code installed, and that
the mediator is running on host04, example properties files might look
like:
For ND01:
netletdaemon.id=ND01
netletdaemon.console=false
netletdaemon.default.protocol=rmi
netletdaemon.facilitator.enable=true
netletdaemon.facilitator.mobilecode=CF01@mct.mediator.CommunicationFacilitator
netletdaemon.facilitator.properties=/mct/configuration/fac.prop
netletdaemon.migrator.enable=true
netletdaemon.migrator.mobilecode=MF01@mct.admin.RemoteMigrationFacilitator
netletdaemon.migration.rmi.host.0=host02
netletdaemon.migration.rmi.name.0=MF02@mct.admin.RemoteMigrationFacilitator
netletdaemon.security.enable=false
For ND02:
netletdaemon.id=ND02
netletdaemon.console=false
netletdaemon.default.protocol=rmi
netletdaemon.facilitator.enable=true
netletdaemon.facilitator.mobilecode=CF02@mct.mediator.CommunicationFacilitator
netletdaemon.facilitator.properties=/mct/configuration/fac.prop
netletdaemon.migrator.enable=true
netletdaemon.migrator.mobilecode=MF02@mct.admin.RemoteMigrationFacilitator
netletdaemon.migration.rmi.host.0=host03
netletdaemon.migration.rmi.name.0=MF03@mct.admin.RemoteMigrationFacilitator
netletdaemon.security.enable=false
For ND03:
netletdaemon.id=ND03
netletdaemon.console=false
netletdaemon.default.protocol=rmi
netletdaemon.facilitator.enable=true
netletdaemon.facilitator.mobilecode=CF03@mct.mediator.CommunicationFacilitator
netletdaemon.facilitator.properties=/mct/configuration/fac.prop
netletdaemon.migrator.enable=true
netletdaemon.migrator.mobilecode=MF03@mct.admin.RemoteMigrationFacilitator
netletdaemon.migration.rmi.host.0=host01
netletdaemon.migration.rmi.name.0=MF01@mct.admin.RemoteMigrationFacilitator
netletdaemon.security.enable=false
The properties file for the Communication Facilitators (fac.prop)
(available on host01, host02 and host03) might look like:
fac.directory.mobilecode=LMCD@mct.mediator.LocalMCDirectory
fac.directory.properties=/mct/configuration/dir.prop
fac.port=6666
fac.mediator.ip=host04
fac.mediator.listener=RML@mct.mediator.RemoteMediatorListener
fac.mediator.name=Mediator
The local directory file (dir.prop) (available on host01, host02
and host03) might look like:
directory.display.enable=true
The above properties files for would be adequate and implement a ring
default migration pattern. However, a forward and backward ring structure
could be implemented as shown in the figure below:
In this example, a secondary set of migration links has been defined
as shown in blue. The added property file statements needed to achieve
this level of logical interconnection might be:
For ND01:
netletdaemon.migration.rmi.host.1=host03
netletdaemon.migration.rmi.name.1=MF03@mct.admin.RemoteMigrationFacilitator
For ND02:
netletdaemon.migration.rmi.host.1=host01
netletdaemon.migration.rmi.name.1=MF01@mct.admin.RemoteMigrationFacilitator
For ND03:
netletdaemon.migration.rmi.host.1=host02
netletdaemon.migration.rmi.name.1=MF02@mct.admin.RemoteMigrationFacilitator
Note that with the numbering scheme chosen for the migration paths defined
in the above example, the blue links become the default migration paths
and the black links the backup.