Mata 99

Optimizing the Migration of Mobile Agents
Guilherme Soares Luís Moura Silva
Departamento Engenharia Informática

Universidade de Coimbra - POLO II
Vila Franca - 3030 Coimbra
PORTUGAL
Email: {fsoares,luis}@dei.uc.pt
Abstract
The paradigm of Mobile Agents is emerging in the field of distributed computing. Several Java-based
platforms have been already implemented and people is now starting to implement some agent-based
applications. In most of the cases, the performance of the applications is an issue of paramount importance.
In this paper, we present a set of optimization techniques that have been implemented in the JAMES
platform, a Java-based mobile agent system that has been developed by the University of Coimbra and
Siemens, and is mainly oriented for telecommunications and network management. The techniques include
some caching schemes, code prefetching, thread and socket pooling and some protocol optimizations. These
techniques are general-purpose enough that can be ported to any other Java-based mobile agent platform. In
the second part of the paper, we present some performance results that show the effectiveness of the proposed
techniques.
Keywords: Mobile Agents, High-Performance, Distributed Computing and Java.
1. Introduction
Most of the existing applications used in the management of telecommunication networks
are based on client/server solutions. This static and centralized approach, where every
element of the network sends the data to a central location has some relevant drawbacks: it
is not flexible, it has problems of scalability and it produces too much traffic in the
network.
The use of Mobile Agents in this kind of applications represents a novel approach and
potentially solves most of the problems that exist in centralized client/server solutions. The
applications can be more scalable, more robust, can be easily upgraded or customized and
they reduce the traffic in the network.
In the last few years the use of mobile agent technology has received an extraordinary
attention from several universities and research institutes. Various efforts are already
underway to standardize mobile agent technology, as MASIF [MASIF] and FIPA [FIPA].
The use of mobile agents has been proposed for many application areas, like Electronic
Commerce, Internet applications, information retrieval, cooperative work, network
management and telecommunications. Several commercial mobile agent systems have
already been presented in the market, including Aglets from IBM [Aglets], Concordia from
Mitsubishi [Concordia], Odyssey from General Magic [Odyssey], Voyager from
ObjectSpace [Voyager], Jumping Beans from AdAstra [JumpingBeans] and Grasshopper
from IKV [Grasshopper].
Optimizing the Migration of Mobile Agents 2
In order to fulfill one of the main requirements of the mobile agent applications - the need
for high performance – some optimization mechanisms should be used. In this paper we
propose a set of techniques to improve the performance of mobile agent systems, including
a flexible distribution of the agent’s code, a code prefetching scheme, a pool of threads and
migration channels and some protocol enhancements.
These optimization mechanisms have been implemented in the JAMES platform, a Java-
based mobile agent infrastructure that has been developed on behalf of Eureka Project
(Σ!1921). This project includes three partners: University of Coimbra (Portugal), Siemens
SA (Portugal) and Siemens AG (Germany). The JAMES platform is mainly oriented for
applications in the area of Telecommunications and Network Management, where
performance is an issue of paramount importance.
The rest of the paper is organized as follows: section 2 presents some related work. Section
3 describes briefly the James platform. Section 4 describes the techniques and mechanisms
that we have implemented to optimize the migration of mobile agents. Section 5 presents
some performance results and section 6 finishes the paper with some conclusions and
future work.
2. Related Work
Most of the existing mobile agent platforms do not implement any special techniques to
achieve high-performance in the migration of agents.
The main exception is the Mole system [Mole] from the University of Stuttgart. The
members of this project have already published some very interesting work in this topic.
In [Hohl97] is described how to design an efficient code migration component, called code
server. Some mechanisms to transport code are analyzed: one that is able to get classes in
an efficient manner and one that is able to get any valid class by its reference. It is also
presented some code replacement policies, showing that a random or a LRU algorithm is a
good starting point for the code replacement scheme.
[Strasser97] presents a performance model for the interaction of agents in mobile agent
systems. It introduces a model where agents can alternatively use remote procedure calls or
agent migrations for the interaction with partners on different locations. The conclusion is
that an alternating sequence of remote procedure calls and agent migrations performs better
than a pure sequence of remote procedure calls or a sequence of agent migrations.
[Iqbal98] presents some efficient algorithms to find optimal agent migration strategies. It is
indicated that the optimal performance of an agent is achieved by a critical sequence of
mixed remote procedure calls and agent migrations.
[Knabe97] presents several strategies to improve performance that are used by a mobile
agent language, called Extended Facile. There are several techniques reviewed that include
allowing agents to use different transmissible representations and performing agent
compilation in a lazy way. Some quantitative measurements have been presented, showing
the effectiveness of these techniques.
3. Overview of the JAMES Platform

The main goal of the JAMES project is to develop an infrastructure of Mobile Agents with
enhanced support for network management. We also try to exploit the use of this new
technology in some telecommunication software products.
______________________________________________________________________________________
Submitted for publication at the MATA’99 (First International Workshop on Mobile Agents for Telecommunication Applications)
The main goals of the JAMES platform are the following: high-performance, security,
fault-tolerance and robustness, support for network management, easy upgrading,
disconnected operation, a 100% pure Java implementation and the integration with
CORBA.
The JAMES Platform provides the running environment for mobile agents. There is a
distinction between the software environment that runs in the manager host and the
software that executes in the network elements: the central host executes the JAMES
Manager while the nodes in the network run a JAMES Agency. The JAMES system will
provide a programming interface that allows the full manipulation of mobile agents. Figure
1 shows a global snapshot of the system, with a special description of a possible scenario
where the mobile agents will be used.
Network
Element
Mobile Agent
JAMES
Manager
Network
Element
JAMES
GUI
Network
Element
Central Host
Mobile Agent
Network
Element
JAMES
agent
JAMES User
Agency Operator
Code Server
JAMES
Application Developer Code Server
Figure 1: An Overview of the JAMES Platform
The host machine that runs the JAMES manager is responsible for the whole management
of the mobile agent system. It provides the interface to the end-user, together with a
Graphical User Interface for the remote control and monitoring of agents, Agencies and
applications. A snapshot of this interface is presented in Figure 2. The James GUI is the
main tool for the management and administration of the platform.
______________________________________________________________________________________
Figure 2: The Graphical User Interface.
Every Network Element runs a Java Virtual Machine and executes a JAMES Agency that
enables the execution of the mobile agents. The JAMES agents will migrate through these
machines of the network to access some data, execute some tasks and to produce reports
that will be sent back to the JAMES Manager. There is a mechanism of authentication in
the JAMES Agencies to control the execution of agents and to avoid the intrusion of non-
official agents. A special protocol was developed to transfer the agents across the machines
in a robust way and atomic to the occurrence of failures.
The programmer writes the applications that are based on a set of mobile agents. These
applications are written in Java and should use the JAMES API for the control of mobility.
The use of Java was motivated for reasons of portability and robustness of the applications.
After writing an application the programmer should create a JAR with all the classes that
make part of the mobile agent. This JAR file is placed in a JAMES Code Server. This
server can be a different machine or in the same machine where the JAMES Manager is
executing. In both cases, it maintains a code directory with all the JAR files available and
the mapping to the corresponding mobile agents.
The JAMES platform was designed with high performance in mind to provide the most
efficient support for telecommunication applications. In order to achieve this goal, we have
integrated several optimization techniques in the platform. These techniques are presented
in the next section.
4. Optimization Techniques
4.1 Flexible Code Distribution
One of the main characteristics of the mobile agent systems is the ability to transport not
only the data but also the code to the different places of the agent’s itinerary. Thereby, the
system should be able to fetch the agent code in a flexible and efficient way.
______________________________________________________________________________________
The majority of the existing platforms provide a central code server, where all the code is
stored. Although the code server ensures a solid structure it does not permit an efficient
migration of the agents through the platform. A single centralized point of request can
easily become a point of bottleneck in the system. Fetching the classes from a single node
can be a very inefficient approach and does not fulfil the needs for high-performance
computing.
The JAMES platform overcomes this problem, by providing a flexible and decentralized
distribution of the code across the entire platform. The code classes of the JAMES agents
are grouped in JAR files, which enables a good naming and versioning policy, while
ensuring that all the components of an agent are viewed as a unique block by the system.
The migration of the code is always based on these archive files and not on single classes.
The agent/JAR names are unique within the entire platform.
The agents must be registered in the platform before they can be used. During the
registration process the agent’s JAR file is stored in the main code repository. This central
server has the JAR files corresponding to all the registered agents. The JAR files are
fetched from this server only if they could not be grabbed from a better alternative place, as
will be described next. This code server can be replicated to increase the availability and
improve scalability, namely through a Primary/Backup approach.
Apart from the central repository of code we have implemented a hierarchical repository
mechanism. There are some different code storage levels that can be used to decentralize
the fetching of the code in order to avoid the congestion in the main repository.
The Agencies have their own disk-based repository of JAR files. This local storage reduces
the time and the network traffic that is needed to transfer the JAR files from another point
of the system. The code can be sent only once to the Agency and it stays there waiting for
future requests. The platform administrator can configure the maximum disk space that can
be used in each Agency.
In every Agency, there is also a main memory cache of agent bytecodes. One agent can
instantiate its objects using the data left by another agent of the same type. The information
is available in bytecodes instead of class objects due to classloader and security restrictions.
This caching level reduces the execution time needed to access the classes in the JAR files.
The amount of space available for the memory cache is also configurable in each Agency.
Each agent running on an Agency has its own private memory cache. All the agent’s
specific code stays in this repository and can be reused during the agent’s lifetime. The data
is composed by class objects instead of bytecodes because it is only accessed by one agent
and, consequently, by one classloader. These objects are transparently garbaged by the
Agency when the agent finishes its execution.
When the available memory or disk space is running below some limit and there is a need
to load new code, some data must be removed from the cache. We used the Least Recently
Used (LRU) replacement algorithm.
Every time an agent arrives at one Agency there is a multi-phase protocol to fetch the
classes of the agent: first, the agent classes are searched in the main memory cache; then
the platform searches in the memory table that contains the available JAR’s. If the JAR file
is not in the local cache, the Agency tries to get it from the previous Agency of the
______________________________________________________________________________________
Itinerary. If the classes could not be fetched from this machine then the Agency contacts
the central code store.
This hierarchical searching process provides a higher flexibility in the code distribution.
There is always a central point where all the code is stored but there are multiple choices
that can be used to improve the performance of the application.
Figure 3 shows the different cache levels that are used in the JAMES Platform.
Agency
Previous
Agency
Agent Agent Agent
Cache Cache Cache
Main
Code
Server
Agency Memory Cache
Replicated
Agency Disk Cache Code
Server
Figure 3: Cache Levels in the JAMES Platform.
4.2 Prefetching Mechanism

The caching of JAR files tries to exploit the locality of code of the mobile agents. For those
cases where the cache is still empty we have implemented a code prefetching technique to
accelerate the distribution of JAR files.
When an agent is created and launched to the James platform it has its own Itinerary of
Agencies. The code of the agent must exist in every Agency of the Itinerary. There is
always an overhead when the classes of the agent are not in the local cache of the Agency.
This overhead can be reduced by informing all the Agencies that some particular agent is
going to execute there. With this information, the Agency can perform some code loading
in advance while the agent is still executing in a previous place of the Itinerary.
The prefetching options are defined in the Manager and are the same for all the Agencies.
The prefetching process can be done by the James Manager or it can be distributed among
the Agencies.
______________________________________________________________________________________
In the first case, the James Manager sends the prefetching information to all the Agencies
of the Itinerary (except the first one). The type of data that is sent depends on the
information that is maintained by the Manager about the caching status of the Agencies. If
the Manager does not have such information it sends a simple prefetching information
packet to all the other Agencies of the Itinerary. If there is a global information about the
caches of the Agencies, the prefetching mechanism can make use of that information. If the
Manager detects that there is no JAR for this agent in a destination Agency, the file can be
sent in advance, so that it can be there when the agent arrives. If the JAR file is in the
Agency’s local disk but the agent classes are not in memory and/or the migration channel
to the next destination is not established, the simple prefetching information packet is sent
to this Agency. Figure 4 represents a sample execution of the prefetching mechanism based
on a Manager with a global information about the caches of the Agencies.
Agency 1 Agent
Data
Manager
Agency 2 Prefetch
Message
Agency 3 JAR file
Figure 4: Prefetching mechanism centralized in the Manager.
In the second case, the James Manager only sends a prefetching information to the second
Agency of the Itinerary. When the Agency receives the message it forwards it to the next
Agency and so on until the information reaches the last Agency of the Itinerary. Since the
Agencies do not have a global view of the cache they only send a generic prefetching
information packet. Figure 5 shows an example of this prefetching model.
Agency 1 Agent
Data
Manager
Agency 2 Prefetch
Message
Agency 3
Figure 5: Prefetching mechanism distributed among the Agencies.
The Agency that receives a prefetching information message can act differently according
to the level of prefetching that is selected by the platform.
______________________________________________________________________________________
There are three different options that can be selected: disk, memory and migration channel.
If the first option is selected the Agency must get the JAR File to its local disk repository.
The second option enforces the Agency to fetch the agent classes to the Agency memory
cache. If the third option (migration channel) is selected, the Agency tries to establish a
socket to the next Agency in the Itinerary, in order to speedup the migration phase.
The Manager uses the prefetching options when its prefetching mode is based on the global
view of the cache of the Agencies. If this is the case, the Manager will send different
prefetching data depending on the selected options.
Figure 6 represents the different options of prefetching available in the James Platform.
3 Prefetching
Options
Memory Cache
1 - JAR
2
2 - Memory
Disk Cache
Agency 3
3 - Migration
Agency 2 Channel
Code Server
Figure 6: Different options of Prefetching.
4.3 Pool of Threads and Pool of Migration Channels

We are concerned not only about the migration aspects of the mobile agents but also with
the efficient usage of system resources. A good control of the platform resources can be
combined with the previous scheme to achieve a better performance.
One of the main aspects that must be taken in account in order to ensure a correct behavior
of a system is the number of executing threads. The platform should have some kind of
mechanisms to control the number of threads since it is not possible to predict how many
agents will execute at a specific moment of time. A mechanism to control the number of
threads can protect the system resources but can also improve the overall performance of a
platform.
We have conducted a comparison study of performance between different platforms

presented in [Silva99]. The study has shown that some of the platforms crashed just in
some stress situations. A close look at the causes of such disasters showed that, sometimes,
they were due to the lack of system resources, including threads. Even when the platforms
did not crash, their performance was largely affected by the absence of a good mechanism
to control the execution of the threads.
The JAMES platform implements a very effective mechanism to overcome this problem.
All the threads that run inside the platform are encapsulated in a class named
JamesThread, that extends the Thread class of the Java API. A complementary
structure has been defined to allow the re-use of the threads, called
______________________________________________________________________________________
JamesPoolOfThreads. This pool is available in every Agency and is composed by

JamesThread objects waiting to be used. Every time a new Thread is needed, the pool is
checked to see if there is some existing Thread to be recycled or if it is necessary to create a
new one. There is a maximum limit after which no more threads can be created. After
being used the threads should return to the pool. This implementation scheme leads to a
great performance improve since we can avoid the overhead time of creating threads every
time they are necessary.
Another system resources that are largely used by mobile agent systems are the migration
channels, established between two Agencies of the Agent’s Itinerary. The absence of any
kind of control over the number of this type of connections can be fatal to the entire
platform. In the same study referred above [Silva99] we have noted that some platforms
have problems when the number of agents is very high because they open a new channel
for every migration. Some time after the beginning of their execution they run out-of
migration channels (sockets), leading to a very low level of performance and, in some
cases, to an undesirable crash.
In the JAMES platform we have implemented a mechanism to prevent this kind of

problems. The migration channels established between two Agencies are not closed after
being created. Instead, they are stored in a pool of migration channels to enable a future
reuse. There is a pool of migration channels in each Agency. Every time an agent wants to
migrate to a new Agency it asks for the opening of a migration connection to that place.
The Agency checks the pool to see if there is any available connection or if it is necessary
to establish a new one. The limit of migration channels that can stay in the pool is also
configurable and there is a closing mechanism every time this limit is reached.
These implementations, based on an effective control and re-use of the system resources,
contribute to a more robust, secure and scalable platform. The performance of the
applications also benefits largely from these techniques.
4.4 Protocol Optimizations

The overall performance is also related with the internal implementation of the migration
protocol. We tried to optimize the inner parts of this protocol, exploiting all the available
techniques of the Java language. We have developed a simple but efficient protocol to
allow the migration of the agents between the nodes of the Itinerary.
The use of buffer streams allows a better control of the flow of the data between the two
parts of the communicating process. The JAMES platform use different buffer sizes,
depending on the agent’s size. This dynamic process can be important for the migration of
the mobile agents.
The reception of different agents is accomplished in parallel; there is no input queue

responsible for all agents. Each agent is received by a separated thread that starts its
execution in a new thread. This new thread will be also responsible for sending the agent to
the next destination. By starting a new thread we can finish all the protocol transactions
while the agent is already executing.
______________________________________________________________________________________
5. Performance Results
In this section we present some experimental results that show the effectiveness of the
optimization techniques that have been described before.
We used a simple mobile agent that roams a network of computers to get a report about the
free memory of each machine. These machines were running Windows NT and JDK 1.2
and were connected through a dedicated 10 Mbit/sec Ethernet network. Each machine was
executing a JAMES Agency, while the JAMES Manager was installed in a separated
computer. The version of the JAMES platform was the 2.0.
We have measured three different results for every different test. The final result is the
average of all these ones, with a standard deviation below 5%.
5.1 Caching Mechanisms

In Figure 7 we present the execution time of the application when we applied the caching
mechanisms of the JAMES platform. We have tested agents with different code sizes. We
used five Agencies to perform this test. The size of the agent data was around 1 KB.
Although the agent only performs a free memory data collection (using 4KB of code), it
also carries and instantiates extra classes to simulate the growth of the agent‘s code.
16.00
14.00
Execution Time (sec)
12.00
10.00 No Cache
8.00 Disk Cache
6.00 Memory Cache
4.00
2.00
0.00
4 KB 100 KB 1 MB
Agent Code Size
Figure 7 – Comparing the performance of the caching levels when increasing the Agent’s code size.
The results show that when using the memory caching mechanisms the performance was
improved up to 380% against the version without cache. The execution time with a disk-
based cache can be 160% faster than without cache. The use of the memory cache can
improve even 80% further the performance when compared to a disk cache
implementation.
This set of results shows that the caching mechanism can reduce significantly the execution
time of a migratory agent. These techniques should be taken in account if we want to
achieve a good performance in a mobile agent system.
______________________________________________________________________________________
5.2 Open in advance the Migration Channels

In the following experiment we will try to show the advantages of opening in advance the
migration channels between two Agencies of the Itinerary. This technique is implemented
has an option of the prefetching mechanism of the JAMES platform.
In Figure 8 we present the execution times with and without pre-established migration
channels. In both cases we have applied the caching mechanisms. We used five agencies to
perform this test; the size of the agent’s code was around 4 KB and the agent’s data size
was near 1KB.
2.500
2.000
1.500 Migration Channel

Closed
Migration Channel
1.000 Opened
0.500
0.000
None Disk Memory
Caching Level
Figure 8 – The results of open in-advance the migration channels.
The use of pre-established migration channels can also contribute to a better performance
in the execution of the mobile agents. In this test case the improvement factor was up to
60 %.
5.2 Code Prefetching

In the next experiments we will show the importance of the code prefetching mechanism.
The mobile agent was executed for the first time in the network, to ensure that the
application did not make use of the caching scheme. The migration channels were also not
established between the Agencies.
In Figure 9 we compare the execution times of the migratory agent for different agent code
sizes, when we applied the different prefetching modes. All the possible options have been
selected: disk, memory and migration channels. We used five agencies to perform this test
and the data size of the agent was near 1 KB.
______________________________________________________________________________________
16.00
14.00

12.00
10.00 No Prefetching
Manager
8.00
Manager Global View
6.00 Agency
4.00
2.00
0.00
4 KB 100 KB 1 MB
Agent Code Size
Figure 9 – Comparing the performance of the prefetching modes.
As we can see in Figure 9, the prefetching mechanism can speed up the migration of the
agents up to 87 %. The best results were achieved when the Manager has a global view
about the caching of the Agencies. Since the Manager has information about the resources
that each Agency has, it can prefetch the JAR file in advance. The other two
implementations have similar execution times. The Agency-based mechanism can be a
good solution in order to decentralize the processing among the Agencies of the network.
The number of Agencies in the Itinerary can be an important factor to measure the
relevance of the prefetching scheme. Figure 10 shows the execution times of the migratory
agent for one, three and five Agencies. We have measured the times without any
prefetching mechanism and with the different modes implemented in the JAMES platform.
All the possible options were used: disk, memory and migration channels. The size of the
agent’s code was near 4 KB and the data size of the agent was near 1 KB.
2.50
2.00
No Prefetching
1.50
Manager
Manager Global View
1.00
Agency
0.50
0.00
1 3 5
Number of Agencies
Figure 10 – Prefetching Mechanism with different number of Agencies.
______________________________________________________________________________________
We can conclude that the effectiveness of the prefetching mechanism is related with the
number of Agencies of the Itinerary. The migration with prefetching is up to 33% and 87%
times faster than the non-prefetching migration, for three and five Agencies, respectively.
The prefetching with a global view about the caches is the fastest and the two other
implementations have similar results.
Figure 11 shows the execution times of the migratory agent in different mobile agent
platforms. We have implemented the same benchmark application on the Aglets
Workbench [Aglets], Voyager [Voyager], Grashopper [Grashopper], Concordia
[Concordia], Odyssey [Odyssey], Swarm [Kovacs98] and James [James].
We have measured the times with and without the prefetching mechanism. The size of the
agent’s code was near 4 KB and the data size of the agent was near 1 KB. We used five
Agencies to perform this test and all of the machines were rebooted before performing this
test.
8.00
7.00
James (Pref.)
6.00
James
5.00 Swarm
Odyssey
4.00
Concordia
3.00 Grashopper
Voyager
2.00
Aglets
1.00
0.00
Figure 11 – Comparison between the performance of different Mobile Agent Platforms.
The results show that the JAMES platform has the better performance of all the mobile
agent platforms that have been tested. Both the JAMES prefetching and non-prefetching
versions are faster than any of the other platforms. The JAMES prefetching implementation
is 100% faster than the non-prefetching one, 120% faster than the second placed platform
(Swarm) and 352% faster than the last platform (Aglets). The JAMES non-prefetching
implementation is 9% faster than the Swarm platform and 123% faster than the Aglets
platform.
We have made a very large set of tests comparing the JAMES platform with eight other
mobile agent platforms [Silva99]. The conclusions show that JAMES has the best overall
performance of execution and produces a very small amount of network traffic. The
robustness is another strong aspect of this platform when compared with the majority of
platforms tested.
______________________________________________________________________________________
The performance results of the caching and prefetching mechanisms seem to be quite
promising and the JAMES platform seems to be very competitive for the applications we
have in mind: telecommunications and network management.
6. Conclusions and future work

James is a mobile agent platform designed to be used with telecommunication and network
management applications. One of the main requirements of these applications is a good
performance of execution. Some techniques have been implemented in the JAMES
platform to provide the most performance for the agent-based applications, namely:
caching and prefetching mechanisms, reusable pools of threads and migration channels and
an optimized agent migration protocol.
The preliminary results show that these techniques are really effective and can improve the
execution of mobile agents. The results also show that JAMES seems to be very
competitive in performance when compared with other existing platforms.
We are now making some tests using compressed JAR’s for the migration of the mobile
agent. In a near future we hope to know in which cases it will pay off to compress or not
the agent’s code. There are several factors that must be taken in account in order to turn the
conclusions as reliable as possible.
Another topic that we plan to explore in a near future is the concept of elastic agents. These
special type of agents can drop some code when they don’t need it or include new code.
These characteristics can optimize the migration performance of the agents, since there is a
significant reduction in the code size that travels with agent through the network.
7. Acknowledgments
This project is partially supported by Agência de Inovação and was accepted in the Eureka
Program (Σ!1921). Special thanks to the rest of the team that is implementing the JAMES
platform, namely: Victor Batista, Paulo Martins, Paulo Simões, Luis Santos , Rodrigo Reis
and António Bernardino
8. References
[Aglets] IBM Aglets Workbench, http://www.trl.ibm.co.jp/aglets/
[Concordia] Concordia, http://www.meitca.com/HLS/Projects/Concordia/
[FIPA] Foundation for Intelligent Physical Agents, http://www.fipa.org/
[James] Project James, http://dsg.dei.uc.pt/James
[JumpingBeans] Jumpinh Beans, http://www.JumpingBeans.com
[Knabe97] Frederick Knabe, ‘‘Performance-Oriented Implementation Strategies for a Mobile Agent
Language’’, in Mobile Object Systems, Christian Tschudin and Jan Vitek, editors, number 1222 in
Lecture Notes in Computer Science series, pages 229-243, 1997. Springer-Verlag.
[Kovacs98] E.Kovacs, K.Rohrle, M.Reich, "Integrating Mobile Agents into the Mobile Middleware", Proc.
2nd Int. Workshop on Mobile Agents, MA’98, pp. 124-135, Stuttgart, Germany, September 1998.
[Ghezzi97] C. Ghezzi, C. Vigna, “Mobile Code Paradigms and Technologies: A Case Study”, Proceedings of
the first International Workshop on Mobile Agents, MA’97, Springer 1997
[Grasshopper] Grasshopper platform, http://www.ikv.de
[Hohl97] F. Hohl, P. Klar, J. Baumann, “Efficient Code Migration for Modular Mobile Agents”, 3rd ECOOP
Workshop on Mobile Object Systems: Operating System support for Mobile Object Systems
(MOS'97).
______________________________________________________________________________________
[Iqbal98] A. Iqbal, J. Baumann, M. Straßer, “Efficient Algorithms to Find Optimal Agent Migration
Strategies”, Universität Stuttgart, Fakultät Informatik, Bericht Nr. 1998/05.
[MASIF] Mobile Agent System Interoperability Facility, http://www.fokus.gmd.de/research/cc/ima/masif/
[Mole] Project Mole, http://www.informatik.uni-stuttgart.de/ipvr/vs/projekte/mole.html
[Odyssey] General Magic Odyssey, http://www.genmagic.com/agents/
[Silva99] L.M.Silva, G.Soares, P.Martins, V.Batista, L.Santos, “The Performance of Mobile Agent
Platforms”, Technical Report, University of Coimbra, submitted for publication.
[Strasser97] M. Straßer, M. Schwehm, “A Performance Model for Mobile Agent Systems”, In: H. Arabnia
(ed.), Proc. Int. Conf. on Parallel and Distributed Processing Techniques and Applications
(PDPTA'97).Vol II, CSREA, pp. 1132-1140.
[Voyager] Voyager, http://www.objectspace.com/voyager/
______________________________________________________________________________________

Mata 99

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Mata 99

Diunggah oleh

Hak Cipta:

Format Tersedia

Optimizing the Migration of Mobile Agents

Guilherme Soares Luís Moura Silva

Departamento Engenharia Informática

Keywords: Mobile Agents, High-Performance, Distributed Computing and Java.

3. Overview of the JAMES Platform

Figure 1: An Overview of the JAMES Platform

Figure 2: The Graphical User Interface.

Figure 3: Cache Levels in the JAMES Platform.

4.2 Prefetching Mechanism

Agency 3 JAR file

Figure 4: Prefetching mechanism centralized in the Manager.

Figure 5: Prefetching mechanism distributed among the Agencies.

Figure 6: Different options of Prefetching.

4.3 Pool of Threads and Pool of Migration Channels

We have conducted a comparison study of performance between different platforms

JamesPoolOfThreads. This pool is available in every Agency and is composed by

In the JAMES platform we have implemented a mechanism to prevent this kind of

4.4 Protocol Optimizations

The reception of different agents is accomplished in parallel; there is no input queue

5.1 Caching Mechanisms

5.2 Open in advance the Migration Channels

1.500 Migration Channel

Figure 8 – The results of open in-advance the migration channels.

5.2 Code Prefetching

Execution Time (sec)

Figure 9 – Comparing the performance of the prefetching modes.

Figure 10 – Prefetching Mechanism with different number of Agencies.

Figure 11 – Comparison between the performance of different Mobile Agent Platforms.

6. Conclusions and future work

Anda mungkin juga menyukai