Mobile Agent Thesis
138
PERFORMANCE ANALYSIS OF MOBILE AGENTS IN WIRELESS INTERNET APPLICATIONS USING SIMULATION A Thesis Presented to The Faculty of the College of Graduate Studies Lamar University In Partial Fulfillment of the Requirements for the Degree Master of Science by Kunal Shah August 2003
-
Upload
pranshu-jaiswal -
Category
Documents
-
view
706 -
download
6
Transcript of Mobile Agent Thesis
PERFORMANCE ANALYSIS OF MOBILE AGENTS IN WIRELESS
INTERNET APPLICATIONS USING SIMULATION
A Thesis
Presented to
The Faculty of the College of Graduate Studies
Lamar University
In Partial Fulfillment
of the Requirements for the Degree
Master of Science
by
Kunal Shah
August 2003
PERFORMANCE ANALYSIS OF MOBILE AGENTS IN WIRELESS
INTERNET APPLICATIONS USING SIMULATION
KUNAL SHAH
Approved:
________________________________ Lawrence Osborne Supervising Professor
________________________________
Hikyoo Koh Committee Member
________________________________
Dehu Qi Committee Member ____________________________ Lawrence Osborne Chair, Department of Computer Science _____________________________ Jack R. Hopper Dean, College of Engineering ______________________________ Jerry W. Bradley Associate Vice President for Research and Dean of Graduate Studies
© 2003 by Kunal Shah
No part of this work can be reproduced without permission except as indicated by
the “Fair Use” clause of the copyright law. Passages, images, or ideas taken
from this work must be properly credited in any written or published materials.
ABSTRACT
Performance Analysis Of Mobile Agents
In Wireless Internet Applications Using Simulation
By: Kunal Shah, M.S.
Lamar University
In today’s information society, users are overwhelmed by the information with
which they are confronted on a daily basis. However, for subscribers of mobile
wireless services, this may present a problem. Wireless devices are connected
via wireless networks that suffer from low bandwidth and also have a greater
tendency for network errors. Additionally, wireless connections can be lost or
degraded by mobility. The mobile agent technology offers very promising solution
to this problem. Mobile agents can migrate from host to host in a network of
computers. Their mobility allows them to move across an unreliable link to reside
on a wired host, next to or closer to the resources that they need to use.
Furthermore, client-specific data transformations can be moved across the
wireless link and run on a wired gateway server, reducing bandwidth demands.
There have been extensive researches going on in the development of the
mobile agent systems. But there are not many efforts in the study of their
performance in real world applications and very few in wireless networks. As a
result, the spread of mobile agent technology in the real world applications
cannot be seen yet. The main obstacles faced by the researchers are the
complexity of evaluating distributed applications in heterogeneous networks and
expenses of building test beds for their experiments. A computer simulator can
overcome these obstacles. A simulator is able to provide users with practical
feedback when designing real world applications.
Thus, the main objectives of this thesis are to implement a tool to simulate
the behavior of mobile agents and to utilize this tool for the performance analysis
of mobile agents in wireless services. The implementation consists of extending
the existing network simulator NS2 to support mobile agents’ simulation. It has
been tried to use IBM’s Aglets API whenever possible to ease both the
understanding of the code and its usage for implementing agent based simulated
applications. NS2, along with the extension made, then has been used to study
the performance of mobile agents in some of their promising applications in
Wireless Internet Services viz. information retrieval. Their performance is
compared to that of the client/server model. The results show that significant
performance improvements can be obtained using mobile agents but only in
certain situations. While in other situations client/server model has better
performance. Such situations has been determined and can be very helpful in
deciding dynamically which one of the two should be used for optimum
performance.
ACKNOWLEDGEMENTS
I am indebted to my advisor Dr. Lawrence Osborne for all the motivation,
support and direction he has provided. He has been an invaluable source of
knowledge and ideas and I appreciate his flexibility in allowing me to pursue my
own research ideas. I would like to thank Dr. Hikyoo Koh for his valuable
guidance and his role on my committee. I am also thankful to Dr. Dehu Qi for his
helpful suggestions as a member of my committee.
I am also grateful to Prof. Paolo Bellavista at DEIS-LIA - Università degli
Studi di Bologna, Italy for his guidelines and support for this research. I would
also like to thank Ms. Donna Blaisdell, Departmental Secretary and Mr. Frank
Sun, Senior System Administrator for always being supportive to me. I would
also like to take this opportunity to thank Mr. Gary Laird, Director Developmental
Studies for sparing his valuable time in proofreading this thesis.
I would like to express my gratitude to my parents for their incredible support.
They have done whatever they could do to make sure that I could get the best
education possible and have always encouraged me to strive for the best. Finally
a special thanks to my wife without whose moral support and encouragement, it
would have been impossible to finish this work.
iii
TABLE OF CONTENTS
LIST OF TABLES vii
LIST OF FIGURES viii
CHAPTER-1 1
Introduction 1
1.1 Motivation 2
1.2 Performance Analysis using Simulation 3
1.3 Organization of the Thesis 3
CHAPTER-2 5
Background and Literature Survey 5
2.1 Overview of Mobile Agents 5
2.1.1 A Software Agent 5 2.1.2 Mobile vs. Stationary Agents 5 2.1.3 Mobile Agents and Mobile Agent Environment 6 2.1.4 Brief comparison of Mobile Agent paradigm to the traditional Client- Server paradigm 7 2.1.5 What Mobile Agents can do for us? 9
2.2 Survey of Mobile Agent Systems 11
2.2.1 Java-based systems 11 2.2.2 Multiple Language Systems 12 2.2.3 Other Systems 13 2.2.4 Brief comparison of Mobile Agent Systems 13
2.3 Competing Technologies and Comparisons 15
2.4 Related Works And Their Contribution 18
CHAPTER-3 21
Mobile Agents in Wireless Internet Services 21
3.1 How Mobile Agents fit in Wireless Networks? 21
3.2 Supports for adapting Mobile Agents in Wireless Services 23
3.3 Potential Wireless Applications of Mobile Agents 27
iv
CHAPTER-4 30
Extending NS2 to Support Simulation of Mobile Agents 30
4.1 Introduction to Network Simulator (NS2) 30
4.1.1 Software Architecture 30 4.1.2 C++ - OTcl Linkage 31 4.1.3 Major Components 33 4.1.4 Further directions 34
4.2 Why NS2? 34
4.3 Design and Implementation of Mobile Agent Model 35
4.3.1 Assumptions 35 4.3.2 Deciding the Inheritance Structure of the Model 36 4.3.3 Transferring Application-level data in NS 38 4.3.4 Design Overview 40 4.3.5 C++ and OTcl linkage for the Model 43 4.3.6 Mobile Agent Model Parameters 49 4.3.5 Mobile Agent Methods 51 4.3.6 Mobile Agent’s Event Listeners 54 4.3.7 Purpose and Functioning of MAgletInst class 55 4.3.8 Methods Implemented in class Context 56 4.3.9 Modeling of Agent’s Timer 58 4.3.10 OTcl Interface for the mobile agent model 61
4.4 Adding mobile agent model to NS package 62
4.5 Model Interactions 64
4.6 Problems encountered and their work-around 68
4.7 Validating the Mobile Agent Model 71
CHAPTER-5 78
Simulating Wireless Applications Using Mobile Agent Model 78
5.1 Information Retrieval- Scenario 1 78
5.1.1 Ideal Conditions for Mobile agent Systems with No Overhead 86 5.1.2 Effect of the Mobile Agent’s Size Overhead 88 5.1.3 Effect of Creation and Marshalling/Serialization Overhead 90 5.1.4 Effect of Number of Servers Required to Visit 92
5.2 Information Retrieval- Scenario 2 94
5.3 Mobile Agents in Middleware for Mobile Device 96
v
5.4 Overall Analysis of the Results 101
CHAPTER-6 105
Conclusion and Future Work 105
6.1 Conclusion 105
6.2 Future Directions 106
REFERENCES 108
APPENDIX: User’s Guide to Mobile Agent Model 113
A.1 Model Parameters Accessible Through OTcl 113
A.2 Procedures Available to User Through OTcl 115
A.3 An Example Script 119
vi
LIST OF TABLES
Table 4.1. Parameters of a Mobile Agent ........................................................... 49
Table 4.2. Parameters of a Context.................................................................... 51
Table 4.3. Methods Implemented in MAgent Class ............................................ 52
Table 4.4. Methods iplemented in Context class ................................................ 57
Table 4.5. Sequence of Interactions ................................................................... 67
Table 4.6 Parameter Values used for Validation ................................................ 74
Table 4.7. Output from Models and their Differences ......................................... 77
Table 5.1. Parameter Values for Scenario-2 ..................................................... 95
Table 5.2. Parameter Values for Simulating Middleware................................... 98
Table A.1. OTcl Parameters for Mobile Agent Object....................................... 113
vii
LIST OF FIGURES
Figure 2.1. Communications using client-server paradigm................................... 8
Figure 2.2. Communications using mobile agent paradigm.................................. 8
Figure 4.1. C++ -- OTcl linkage. ......................................................................... 31
Figure 4.2. Major components in NS. ................................................................. 33
Figure 4.3. Application layer in NS. .................................................................... 37
Figure 4.4. Transferring user level data in NS. ................................................... 39
Figure 4.5. Class hierarchies for the model. ....................................................... 41
Figure 4.6. Class relationship of the model. ....................................................... 43
Figure 4.7. C++ and OTcl linkage for the model. ................................................ 44
Figure 4.8. Adding mobile agent model to NS. ................................................... 63
Figure 4.9. Model interactions for an example scenario. .................................... 66
Figure 4.10 Validation of the Mobile agent Model............................................... 73
Figure 4.11. Variation of throughput with agent’s selectivity............................... 75
Figure 4.12. Comparison of mathematical and simulation model. ...................... 75
Figure 5.1. Information retrieval - scenario 1. ..................................................... 79
Figure 5.2. Visualization of scenario 1 using NAM. ............................................ 80
Figure 5.3. Performance comparison- ideal conditions....................................... 87
Figure 5.4. Performance ratio mobile-agent/client-server................................... 87
Figure 5.5. Performance comparisons with variable agent code size................. 89
Figure 5.6. Performance comparisons with system overhead. ........................... 91
Figure 5.7. Performance comparisons with variable number of servers. ............ 93
Figure 5.8. Performance comparisons- scenario 2. ............................................ 95
viii
Figure 5.9. Traditional and mobile agent based middleware .............................. 97
Figure 5.10. Mobile agent / Client-server comparisons ...................................... 99
Figure 5.11. Effect of number of interactions.................................................... 100
Figure 5.12. An example usage of a service agent storing simulation results. . 102
Figure 5.13. Performance optimization using simulation results....................... 103
ix
x
Shah 1
CHAPTER-1
Introduction
In the recent years, growth of the Internet has exploded with the appearance
of World-Wide Web. Today, network and computer technology along with the
services and information available on the Internet are growing so fast that we will
soon reach to the point where hundred of millions of people will have fast,
pervasive access to a substantial amount of information from anywhere and
anytime. The advancement experienced in the area of wireless personal
communications is enormous. The European cellular system GSM has received
an impressive acceptance and spread rapidly over the world. Also office
environments and industrial installations have benefited from the introduction of
various standards like IEEE 802.11. The growth of wireless telecommunications
coupled with proliferation of portable computing equipment (laptops, personal
digital assistants) has stimulated the interest for the anywhere-anytime
computing, also known as “nomadic computing”. Nomadic computing aims to
provide users with access to popular desktop applications, applications
especially suited for mobile users, and basic communication services. Observing
the growing demands of mobile users, it can be predicted that the next
generation wireless networks will be burdened with bandwidth-intensive traffic
generated by applications such as web browsing, traveler information systems,
video and games. However, the available resources (e.g. bandwidth) for
supporting such applications are extremely limited. Additionally wireless
Shah 2
networks have a greater tendency for network errors and also wireless
connections can be lost or degraded by mobility.
The mobile agent technology offers very promising solution to these
problems. Mobile agents can migrate from host to host in a network of
computers. Their mobility allows them to move across an unreliable link to reside
on a wired host, next to or closer to the resources that they need to use.
Furthermore, client-specific data transformations can be moved across the
wireless link and run on a wired gateway server, reducing bandwidth demands.
1.1 Motivation
For the past several years, researchers and developers have put substantial
efforts in the development of the basic technology for mobile agents. This has
resulted into several robust and efficient but monolithic mobile agent systems.
Researchers have now pointed out (Kotz, Gray, and Rus 2002) that this
monolithic approach to mobile agent systems is harming the spread and
acceptance of mobile code in general. Wireless application developers are
hesitant to create applications that require use of a new, large, monolithic system
that are not tailored to their specific needs and thus resulting in significant
overheads. Hence the performance benefits offered by the mobile agents, as
discussed above, are not clear yet. There are only few studies done on
quantitative performance of mobile agents. As a result, there has been a little
motivation for developers to use mobile agents.
Shah 3
Thus, in order to motivate the use of mobile agents it is required to show
those in other fields including application development, that mobile agents are
valuable and for that, more quantitative study on mobility’s value is required.
1.2 Performance Analysis using Simulation
Although the requirement of more performance studies is understood now,
there are many hindrances in the way of accomplishment of these studies. The
most prominent is the complexity of evaluating the performance of mobile agent
applications in heterogeneous networks, typical of wireless applications. The cost
of building test-bed or actual systems for performance analysis is sometimes not
effective or even not feasible. The intensity of the problem increases, as more
and more real world applications deploying mobile agents are proposed and
each need different configuration parameters for performance studies. For these
reasons, it is necessary to build a simulation model of the general mobile agent
behavior and study it as a surrogate for an actual system.
In this thesis, we have tried to build a model for simulating the general
behavior of mobile agents by extending the existing network simulator NS2.
Using this model, the performance of the mobile agents is studied and compared
with more traditional client-server approach.
1.3 Organization of the Thesis
The rest of the thesis is organized as follows. Chapter 2 gives background on
mobile agents including an overview of major mobile agent systems and other
competing technologies. It also discusses the research work relevant to this
Shah 4
thesis. Chapter 3 further details the appropriateness of mobile agents in wireless
services and lists the support provided by recent researches in adapting them in
wireless networks.
Chapter 4 details the extension provided to NS2 in order to support mobile
agents and the actual implementation of mobile agent model. Chapter 5
discusses the performance of some of the potential mobile agent applications in
wireless services with both mobile agent and client-server paradigms using NS2.
Chapter 6 concludes this thesis with a note on future research directions.
Shah 5
CHAPTER-2
Background and Literature Survey
2.1 Overview of Mobile Agents
2.1.1 A Software Agent
As per the IBM’s definition (Lange and Oshima 1998), an agent is a software
object that
• is situated within an execution environment
• acts on behalf of others in an autonomous fashion.
• performs its actions in some level of pro-activity and reactivity
• exhibits some levels of the key attributes of learning, cooperation, and
mobility.
2.1.2 Mobile vs. Stationary Agents
Mobility is an orthogonal property of agents. That is, all agents are not
necessarily required to be mobile. An agent can remain stationary and
communicate with the surroundings by conventional means like remote
procedure calls (RPC) and remote object invocation (RMI) etc. The agents that
do not or cannot move are called stationary agents. On the other side, a mobile
agent is not bound to the system where it begins execution. The mobile agent is
free to travel among the hosts in the network. Once created in one execution
environment, it can transport its state and code with it to another execution
environment in the network, where it resumes execution.
Shah 6
2.1.3 Mobile Agents and Mobile Agent Environment
A mobile agent must contain all of the following models: an agent model, a
life-cycle model, a computational model, a security model, a configuration model
and finally a navigation model. A working definition of a mobile agent can be
given as follows (Jain, Anjum, and Umar 2000):
“A mobile agent consists of a self-contained piece of software that can
migrate and execute on different machines in a dynamic networked
environment, and that senses and (re) acts autonomously and proactively
in this environment to realize a set of goals or tasks.”
The software environment in which the mobile agents exist is called mobile
agent environment. Following is the definition of mobile agent environment
(Mahmoud 2001):
“A mobile agent environment is a software system distributed over a
network of heterogeneous computers. Its primary task is to provide an
environment in which mobile agents can execute. It implements the
majority of the models possessed by a mobile agent.”
The above definitions state the essence of a mobile agent and the
environment in which it exists. The mobile agent environment is built on top of a
host system. Mobile agents travel between mobile agent environments. They can
communicate with each other either locally or remotely. Finally, a communication
can also take place between a mobile agent and a host service.
Shah 7
2.1.4 Brief comparison of Mobile Agent paradigm to the traditional Client-Server
paradigm
Today, client-server paradigm enjoys various techniques like remote
procedure calling (RPC), remote object-method invocation (like Java RMI or
CORBA) etc. The RPC paradigm, for example, is the prominent technique of the
client-server paradigm. It views computer-to-computer communication as
enabling one computer to call procedures in another (White 1996). Each
message that the network transports either requests or acknowledges a
procedure’s performance. Two computers whose communication follows the
RPC paradigm have to agree upon the effects of each remotely accessible
procedure and the types of its arguments and results. This agreement constitutes
a protocol. For an example, as shown in Figure 2.1 (White pg. 7), a client
computer initiates a series of remote procedure calls with a server in order to
accomplish a task. Each call involves a request sent from client to server and a
response sent from server to client. Thus the salient feature of client-server
paradigm is that each interaction between the client and the server requires two
acts of communication. That is, ongoing interaction requires ongoing
communication.
Shah 8
Remote Interactions
User
Remote Server
Server
App. Client App.
Figure 2.1. Communications using client-server paradigm.
Local Interactions
User
Remote Server
ServerApp.
MobileAgentMobile
Agent
Figure 2.2. Communications using mobile agent paradigm.
In contrast to client-server paradigm, the mobile agent paradigm views
computer-to-computer communication as enabling one computer not only to call
procedures in another, but also to supply the procedures to be performed. Each
message that the network transports consists of a procedure whose performance
the sending computer either began or continued and the receiving computer is to
continue and the data which are the procedure’s current state. Two computers
Shah 9
whose communication follows the mobile agent paradigm have to agree upon the
instructions that are allowed in a procedure and the types of data that are
allowed in its state. This agreement constitutes a language. This language
provides instructions that allow the procedure to examine and to modify its state,
making certain decisions and call procedures provided by the receiving
computer. But here the procedure calls will be local to the receiving computer,
which is an important advantage of the mobile agent paradigm. Figure 2.2 (White
pg. 7) represents the same example scenario as before but using mobile agent
paradigm. Here the client computer sends an agent to the server whose
procedure there makes the required requests to the server. The dotted line in
Figure 2.2 shows the previous movement of the agent. All the request and
responses in this case are local to the server and no network is required to
complete a task. Thus the salient feature of mobile agent paradigm is that each a
client computer and a server can interact without using the network once the
network has transported an agent between them. That is, ongoing interaction
does not require ongoing communication.
2.1.5 What Mobile Agents can do for us?
The mobile agents have several strengths. The following is the brief
discussion of seven good reasons for using mobile agents (Lange and Oshima
1999):
1. They reduce network load: The main motivation behind using mobile
agents is to move the communication to the data rather than the data to
the computations. Distributed systems often required multiple interactions
Shah 10
to complete a task. But using mobile agent allows us to package a
conversation and send it to a destination host. Thus all the interactions
can now take place locally. The result is enormous reduction of network
traffic. Similarly instead of transferring large amount of data from the
remote host and then processing it at the receiving host, an agent send to
the remote host can processed the data in its locality.
2. They overcome network latency: Certain real-time systems require
immediate action in response to the changes in their environment. But a
central controller cannot respond immediately due to the network latency.
Here mobile agents can be a good solution as they can be dispatched
from a central controller to act locally in the system and thus can respond
immediately.
3. They encapsulate protocols: Due to the continuous evolution of existing
protocols in a distributed system, it is very cumbersome to upgrade
protocol code property in each host. Result may be that protocols become
a legacy problem. Mobile agents are able to move to remote hosts in order
to establish “channels” based on proprietary protocols.
4. They execute asynchronously and autonomously: This is the reason why
mobile agents are so promising in wireless networks. Due to the fragile
and expensive wireless network connections, a continuous open
connection between a mobile device and a fixed network will not be
always feasible. In this case the task of the mobile user can be embedded
into mobile agents, which can then be dispatched into the fixed network
Shah 11
and can operate asynchronously and autonomously to accomplish the
task. At a later stage the mobile user can reconnect and collect the agent
with the results.
5. They adapt dynamically: Mobile agents are capable of sensing their
execution environment and take decisions based on that dynamically.
6. They are naturally heterogeneous: Mobile agents are generally
independent of the computer and the transport layer and depend only on
their execution environment. Hence they can perform efficiently in any
type of heterogeneous networks.
7. They are robust and fault-tolerant: The dynamic reactivity of mobile agents
to unfavorable situations makes it easier to build robust and fault-tolerant
distributed systems.
2.2 Survey of Mobile Agent Systems
Industry has invested a lot of effort in developing mobile agents. It has
effectively led the development of mobile agent systems. Mobile agent systems
can be broadly classified into three types as follows:
• Java-based systems
• Multiple-language systems
• Other systems
2.2.1 Java-based systems
• Aglets: Aglets is one of the best known and most widespread mobile agent
systems today (Lange pg. 5). It was developed at the IBM Tokyo
Shah 12
Research Lab (“IBM” 1998). Aglets was one of the first Java-based
systems. It has a stable interface and large base of users. Despite its
popularity, Aglets was never productized within IBM in the traditional way.
Aglets is available for free. Aglets uses an event-driven model. Like most
other commercial java-based agent systems, they move the agent objects
code and data, but not thread state while migrating from one machine to
other (weak migration).
• Concordia: Concordia is also a java-based mobile agent system that has a
strong focus on security and reliability (Walsh, Paciorek, and Wong 1998).
It was developed at the Mitsubishi Electric ITA Laboratory in Waltham,
Massachusetts. They also implements weak migration. In Concordia,
agents, events and messages can be queued, if the remote site is not
currently reachable. Agents are protected from tampering through
encryption while they are in transmission or stored on disk. Concordia is
publicly available in binary form.
• MOA: MOA (Mobile Objects and Agents) is developed at The Open Group
Research Institute (Milojicic, Chauhan, and laForge 1998). It is also written
in Java.
2.2.2 Multiple Language Systems
• D’Agents: D’Agents (Kotz et al. 1997) was previously known as Agent Tcl.
It supports agents written in Tcl, Java and scheme, as well as stationary
agents written in C and C++. D’Agents are mainly used for many research
activities internally, such as those exploring security mechanisms,
Shah 13
scalability, network sensing and planning services, market based resource
control and support for mobile computing environments.
• Ara: Ara started with supporting agents written in Tcl and C/C++, but now
it also supports Java. The C/C++ agents are compiled into an efficient
interpreted bytecode called MACE- this bytecode is sent from machine to
machine. Unlike other multiple-language system, Ara is multi-threaded
which provides it with significant performance advantages. It supports
strong mobility.
2.2.3 Other Systems
• Telescript: Telescript was the first commercial mobile agent system
developed (White pg. 7). A Telescript agent is written in an imperative,
object oriented language, which is similar to Java and C++, and is
compiled into byte codes for a virtual machine that is part of each server.
• Messengers: The Messenger project uses mobile code to build flexible
distributed systems and not specifically mobile agent systems. In their
system, computers run a minimal operating system of their own called
Messenger Operating System (MOS), that can send and receive
messengers, which are small packets of data and code written in their
programming language MO.
2.2.4 Brief comparison of Mobile Agent Systems
All the mobile agents systems have the same general architecture. A system
server on each machine accepts incoming agents, and for each agent, starts up
Shah 14
an appropriate environment, loads the agent’s state information into the
environment, and resumes agent execution. However, some differences are
quite notable. Some systems, like Java-based systems described in section
2.2.1, have multi-threaded servers and run each agent in a thread of the server
process itself while some other systems have multi-process servers and run each
agent in a separate interpreter process and the rest uses some combination of
these two extremes. Mobile agent systems generally provide one of the two
types of migration:
1. Strong migration that captures an agent’s object state, code and control
state, allowing it to continue execution from the exact point at which it left
off.. The strong migration is more convenient for the end programmer, but
ore work for the system developer since routines to capture control state
must be added to the existing interpreters.
2. Weak migration that captures only the agent’s object state and code, and
then calls a known entry point inside its code to restart the agent on the
new machine. All the java-based systems do not capture an agent’s
thread (or control) state during migration and thus use weak migration.
This is because thread capture requires modifications to the standard
Java virtual machine. In other words, thread capture means that the
systems could be used with one specific virtual machine, significantly
reducing market acceptance.
Shah 15
2.3 Competing Technologies and Comparisons
Each of the strengths of the mobile agents, as discussed in section 2.1.5,
is a reasonable argument for using mobile agents. But it is important to realize
here that none of these strengths are unique to mobile agents (Chess, Harrison,
and Kershenbaum 1995). Any specific application can be implemented with other
techniques. These other techniques are specified below along with their
comparison (Brewington et al. 1999) to mobile agent paradigm.
• Message passing and remote invocation: The basic differences in
between RPC and mobile agent paradigm have been already pointed out
in section 2.1.4. The main advantage of mobile code (including mobile
agents) over message passing and remote invocation is bandwidth
conservation and latency reduction because the mobile code can be sent
to the network location of the resource. The mobile code can invoke as
many server operations as needed to accomplish its task and no
intermediate data is required to be transferred across the network.
Moreover, once the code has been sent from client side to the server side,
it will not need the link until it is ready to return back with a result. Thus, it
can continue its task even if the network link between client and server
machines goes down. The server can provide a generic service, which
suits a large spectrum of requirements from all the potential client of the
service. But in order to provide a generic service, the server will have to
export a parameterisable interface and the complexity of this interface
increases with the diversity of the clients needs.
Shah 16
• Process migration: Process-migration systems do not allow the processes
to behave autonomously. Instead, most are designed to transparently
move processes from one machine to another to balance load. On the
other hand, mobile agents can move when and where they want,
according to their own application-specific criteria.
• Remote evaluation, applets and servlets: Remote evaluation is an
extension to RPC in which the client is allowed to send the procedure
code to the server, rather than just the parameters for an existing
procedure. Applets and servlets are the Java programs that are
downloaded by a Web browser or uploaded into a Web server
respectively. Thus all three of the above represent some type of mobile
code techniques. But mobile agents are much more flexible than these
other forms of mobile code. There are several reasons behind this
argument.
1. A mobile agent can move from a client to server or from a server to
client. All the above technologies allow code transfer in only one
direction.
2. A mobile agent can choose when and where should it move. This is
not the case with other forms of mobile code, e.g. Java applets are
downloaded onto a client machine only when a human user visits
an associate Web page.
3. A mobile agent can move as many times as desired and can also
spawn off child agents at any position in the network as required in
Shah 17
order to accomplish its task. On the other side, most
implementations of remote evaluation along with all Web browsers
and servers that support applets and servlets, do not allow the
mobile code to move or spawn additional mobile code onto different
machines, thus not allowing any sequential migration. Instead the
client must interact with each resource in turn.
• Application-specific solutions: The obvious advantage of mobile agents
against some application-specific solutions like specialized query
languages or dedicated proxies pre-installed at specific network locations
are their flexibility and ease of implementation. An application can send
its own proxy to any arbitrary location on the network and also can
relocate it depending on the changes in the network condition. Similarly a
server can easily make its operations visible to visiting mobile agents
rather than implementing an application-specific language.
• Summary: Although all the tasks that a mobile agent can perform are not
unique to the mobile agent paradigm, different applications must use
different techniques to accomplish each of these tasks. Thus, a true
strength of mobile agents is that a wide range of distributed applications
can be implemented efficiently, easily and robustly, using a single, general
framework.
Shah 18
2.4 Related Works And Their Contribution
Numerous mobile agent systems have been developed over the past decade
by researchers all over the world. However, little work has been done in studying
the mobile agent’s performance and very few have studied real-world wireless
applications. This chapter discusses the most relevant work in the studies of
overall mobile agent’s performance.
Dikaiakos and Samaras (Dikaiakos and Samaras 2000) introduced a
hierarchical framework for the quantitative performance analysis of mobile agent
systems. They specified this framework as a hierarchy of benchmarks, which
may enable the characterization of the performance of some of the key
components of the mobile agent systems. They also proposed a set of micro-
benchmarks to implement the lower level of their benchmark hierarchy. Their
framework has helped this work in focusing the study at the application level by
using the micro-level metrics as parameters.
Strasser and Schwehm (Strasser and Schwehm 2000) proposed a
mathematical model for the performance analysis of the mobile agent system
using parameters derived from their Mole agent system. They used this model to
study an abstract application with a single mobile agent that may visit several
servers and also validated the model by using its results in a small experimental
application. Their derived model has helped in identifying some of the
parameters and also in validating the simulation model implemented during this
study.
Shah 19
Jain and Anjum (Jain pg. 6) also developed an analytical model to quantify
the performance benefits of using mobile agent technology and compare it to that
of client-server techniques for retrieving information on behalf of a mobile user.
They have studied the same example scenario as used in this thesis and is
discussed in section 5.1 of chapter 5, but have not given any experimental or
simulation results.
Ismail (Ismail, Hagimont, and Mossiere 1999) and developed a minimal
mobile agents platform to measure the cost of the basic Java mechanisms
involved in the implementation of the mobile agent platform. They compared the
performance of this minimal agent system, Aglets and Java-RMI (representing
the client-server paradigm) for two applications namely forward application and
compress application. Their forward application is similar to the scenario 2
considered in section 5.2 of chapter 5. But they have studied it for only wired
networks as the user was accessing the servers through a wired link.
The research team involved in developing the D’Agent mobile agent system
at the Dartmouth College has also performed some performance analysis based
on their D’Agent system. These mainly include the scalability experiments
comparing the mobile agent approach to the client-server approach (Gray, Kotz,
and Peterson 2001), wherein the researchers determined the maximum number
of agents that can be supported by a server simultaneously under various
parameters. They have also studied the performance of mobile agents in a data-
filtering application where mobile client is required to filter information from a
large data stream arriving across the wired network. They developed an
Shah 20
analytical model and used parameters from filtering experiments conducted
during a US Navy Fleet Battle Experiment to explore the model’s implications.
But they have not provided any simulation or experimental validation of their
analytical model.
There has been little simulation work for mobile agent systems. Simulation
work mainly includes (Bandyopadhyay and Krishna 1999) which considers the
use of mobile code for search operations on remote file systems. But their
simulation model was specific to test only the considered application and cannot
be used for the study of general-purpose real-world applications. The simulation
done in (Spalink, Hartman, and Gibson 1998) studies the use of mobile agents
for message-delivery in ad hoc wireless networks but was concerned only with
the performance analysis of their protocol and was not tried to model the
behavior of the mobile agent system.
To our knowledge, this is the first try to simulate the basic behavior of the
mobile agent system by extending a common general-purpose simulator, with the
help of some previously derived analytical models. Furthermore, effectiveness
and ease of the simulation model for analyzing different real-world applications
(particularly for the wireless applications) is shown.
Shah 21
CHAPTER-3
Mobile Agents in Wireless Internet Services
3.1 How Mobile Agents fit in Wireless Networks?
A mobile agent programmer has an option that is not available to the
programmer of a traditional distributed application: to move the code to the data,
rather than moving the data to the code. Moving code may be faster in many
situations where the agent’s code is smaller than the data that would be moved
otherwise. Or, it may be more reliable because the application is only vulnerable
to network disconnection during the agent transfer, not during the interaction with
the resource.
These characteristics of mobile agents make mobile agent technology
especially appealing in wireless networks. On the other side traditional client-
server paradigm may not be so useful to wireless networks in certain cases. The
following characteristics (Chess pg. 15) of wireless devices like laptop and
notebook computers, as well as portable computing devices like personal digital
assistants (PDAs) and cellular phones strongly supports the use of mobile agent
technology.
• They are only intermittently connected to a network, hence have only
intermittent access to a server. The use of mobile agent here can be
advantageous. The mobile client has the ability to create an agent request
– possibly while disconnected launch the agent during a brief connection
Shah 22
session, and then immediately disconnect. The response, if any, is
collected during a subsequent connection session.
• Even when connected, they have only relatively low-bandwidth
connections, and this seems likely to remain true in the near future. The
mobile agent has the ability to perform both information retrieval and
filtering at a server, and to return to the client only the relevant information.
Thus the information transmitted over the network is minimized, which has
significant effect on cost for devices connected by wireless networks.
• They have limited storage and processing capacity. The wireless devices
always suffer from both processing and storage limitations. The problem is
more acute with growing demand of nomadic computing with small
handheld devices. The ability of mobile agents to perform both information
retrieval and filtering at a remote server and to bring only the information
relevant to the client can be very helpful here. Thus, no or minimum
processing is required at the mobile device along with minimum storage
requirements.
Thus, the mobile agents play the important role in wireless networks of
providing support for wireless applications. But are mobile agents the only option
here? The answer to this question is “no”. Actually, as discussed earlier, there is
no mobile agent application that is unique to them, i.e. any specific application
can be implemented just as efficiently and robustly with some other techniques.
For example consider the role of agents in remote searching and filtering. If all
the information were stored in structured databases, it would be sufficient to send
Shah 23
only a single message to the server containing SQL statements and perhaps
perform backend filtering on the search results. But most of the world’s data is in
fact, in flat, free text files. Hence remote searching and filtering requires the
ability to open files, read, filter etc. Mobile agent is certainly a reasonable
approach here. But they are not the only way to perform this service. A search
engine installed at the server (Chess pg. 15) could achieve the same results,
without requiring the danger of malicious agents.
Thus, it is very obvious that the wireless networks do have a real problem as
far as the provision of Internet Services are concerned and that the mobile
agents do have advantages for attaching mobile devices to networks. But it is still
not clear whether the servers of entire network should be adapted to meet the
requirements of the mobile agent technology.
3.2 Supports for adapting Mobile Agents in Wireless Services
The application of mobile agents in provision of wireless services to the
mobile devices has been studied extensively in recent years. As a result, many
mobile agent systems have provided notable supports for facilitating mobile
agents in this scenario. These supports can be broadly classified as follows:
• Support for Disconnected Operation: As discussed before, one of the
major problems of wireless networks is the frequent disconnection of the
mobile user for variant period of time. Thus, in order to improve the
functionalities of wireless services it is necessary for a mobile agent
system to support disconnected operations. For example, when a mobile
agent tries to return to its home machine with final results, that machine
Shah 24
might be disconnected. Thus, the agent must have some way to
determine when the home machine reconnects. A simple approach to this
can be continuous polling after a specific time interval. Such an approach
not only wastes network resources but also fails immediately if home
machine reconnects for only brief periods, a typical characteristic of a
mobile device. Hence a few other approaches have been proposed.
1. D’Agents has devised a docking system (Gray et al 1996), where
each mobile device is paired with a permanently connected dock
machine. When a mobile agent is unable to migrate to a home
mobile device, it moves to the corresponding dock machine and
waits there. When the mobile device reconnects, it notifies the dock
machine of its new network address, and the dock machine
forwards all waiting agents.
2. AMASE (“ACTS” 1999) have proposed another approach in which
a special service called Kindergarten Service is used to support
disconnected operation. The mobile agent here can use this service
if it is unable to reach the home machine as well as any other
destination. The main idea is to suspend the mobile agent till the
destination is accessible again. The Kindergarten service stored the
mobile agent in the local database and registers itself to a central
database. Whenever the destination system is available, a
NotifyService is started and the corresponding Kindergarten service
is notified.
Shah 25
3. Magenta (Hadjiefthymiades, Matthaiou, and Merakos 2002)
provides both tolerance of execution environment failures and a
directory service for agents. When a mobile unit reconnects after a
period of disconnection, this directory service enables it to track the
progress of all the agents it has dispatched.
• Support for different types of Portable Devices: Portable mobile
devices have very limited hardware and software resources, and hence it
would be very difficult or almost impossible to run an agent platform on
such devices, e.g. cellular phone. Also, due to heterogeneous nature of
different portable device, it will be almost impossible for the service
provider to statically predict what version will fit to the current user device.
Thus it is necessary to adapt the mobile agent system to provide services
to the small mobile devices. Many solutions have been proposed.
1. MobiAgent (Hadjiefthymiades pg. 25) uses architecture in which
the agent platform runs on a remote host (called Agent Gateway)
and not on the mobile device. The mobile device uses the KVM1 as
their Java virtual machine and MIDP (Sun 2002) as a platform for
developing applications. In order to use a mobile agent, the user is
provided with a MIDP application that can run on the mobile
device. User creates his profile using this application and agent
based on that profile is dispatched by the gateway. Similarly user
gets the result from the gateway using similar application. 1 The KVM (or Kilo Virtual Machine) is a complete Java runtime environment for small devices. It is specifically designed from the ground up for small, resource-constrained devices with few hundred bytes of total memory.
Shah 26
2. Many mobile agent bases architectures like AMASE and SOMA
(Bellavista and Corradi 2002) are putting extensive research efforts
to achieve high degree of scalability for various device platforms,
ranging from desktop computers to handheld devices. They use
dynamic code distribution, typical of MAs, to serve the mobile
device with only the components they need at a particular time.
This is very important in portable device because of their hardware
and software limitations and their heterogeneity. Thus, mobile
agents can either install or discard the service components as
required.
• Support for Location and Context Awareness: Location and context
awareness are very important for mobile agent paradigm, since this
visibility allows mobile agent to make mobility decisions and also allows
the application to make design and management choices dynamically.
Hence various mechanisms have been adopted for allowing the mobile
agent to detect the current state of its network connection and also to
locate other agents that can serve its needs. Various tools provided for
network sensing (Gray pg. 21) often includes:
1. A tool to determine whether the current host is physically connected
to the network.
2. A tool to determine if the specific host is reachable.
3. A tool to determine expected bandwidth to a remote host.
Shah 27
In order to locate other agents to fulfill its needs, an agent needs access to
some discovery services containing dynamic index of agents and their
locations. Different agent architectures use different methods to
implement these services. But generally, discovery services consist of a
distributed or centralized database of service agents name and locations.
Each service agent needs to register with this service.
3.3 Potential Wireless Applications of Mobile Agents
Several mobile agent researchers have proposed to use mobile agents in
various wireless applications. The following applications can be potentially
deployed more efficiently using mobile agents.
• Information Retrieval: The most prominent application of the mobile
agents is in distributed information retrieval. The information available in
Internet is growing exponentially at every moment. Also the information is
widely distributed. The information that can be retrieved using a search
engine has its own limitations. Hence, for getting a certain set of
instructions it is necessary to search different network sites. Sometimes
this needs querying a series of servers one by one to get a desired result.
It may also the case that the query to the next server needs the result from
the previous server. Using traditional methods of communication like RPC
can result in significant overhead both in terms of wireless bandwidth
consumption and latency or total query time. The deployment of mobile
agent technology can significantly improve the application’s performance.
This is because of the ability of mobile agent to roam autonomously in the
Shah 28
wired network till the information is gathered and hence no need for
intermittent communication through the wireless channel.
• Filtering Data Streams: The second prominent application of mobile
agents is in filtering (Kotz et al. 2002) the bulk amount of result data to
return only what is relevant to the mobile user. Clearly, the agent avoids
the transmission of unnecessary data, but does require the transmission
of agent code from client to server. If the agent code is reasonable
enough, a great saving in bandwidth and time can be attained.
• QoS Provision in Wireless Multimedia Applications: The development and
the deployment of multimedia services should meet the increasing user
expectations and the growing requirements for QoS and should face the
increasing heterogeneity in access devices. In this context, the traditional
end-to-end model is showing its limitations. The network infrastructure
should play an active execution role. Mobile agents are highly suitable for
the implementation of active services (Baschieri, Bellavista and Corradi
2002), since they provide many active service properties like control
decentralization, service tailoring to user requirements and resource
availability, and adaptation of services in response to modifications in
network resources.
• Proxy based Personalized Services to Portable Devices: A lot of
architectures have been proposed for supporting the portable devices for
wireless Internet services. Most of them are based on a proxy-based
middleware using mobile agents. It is not necessary to run an agent server
Shah 29
on the user’s device, rather user needs to provide a profile based on his
requirements to a gateway server on the wired network acting as a proxy
for the mobile device. This proxy then creates and launches agents for the
user. In some architectures proxies are themselves deployed as a mobile
agent and thus enabling their dynamical installation when and where
necessary. Such proxy can follow the mobile device to continue serving it
personalized services.
• Commercial Wireless Services: Some of the architectures using mobile
agents have also proposed wide range distributed commercial wireless
services. Mobile agent based wireless access to banking services
implemented by AMASE (“ACTS” pg. 25) is a very good example.
Although the potential applications of mobile agents have been pointed out
and some of them are already implemented, the wide range acceptance of such
applications is not visible yet. The reason behind that, as discussed before, is
monolithic nature of mobile agent systems and lack of awareness in other fields.
This awareness can be brought by more performance studies of mobile agents
paradigm and attacking their shortcomings.
Shah 30
CHAPTER-4
Extending NS2 to Support Simulation of Mobile Agents
4.1 Introduction to Network Simulator (NS2)
NS2 is an object-oriented, discrete event-driven network simulator developed
at UC Berkeley written in C++ and OTcl. NS2 is very useful for developing and
investigating variety of protocols. These mainly includes protocols regarding TCP
behavior, router queuing policies, multicasting, multimedia, wireless networking
and application-level protocols.
4.1.1 Software Architecture
NS software promotes extensions by users. It provides a rich infrastructure
for developing new protocols. Also, instead of using a single programming
language that defines a monolithic simulation, NS uses the split-programming
model in which the implementation of the model is distributed between two
languages (Breslau, Estrin, and Fall 2000). The goal is to provide adequate
flexibility without losing performance. In particular, tasks such as low-level event
processing or packet forwarding through simulated router require high
performance and are not modified frequently once put into place. Hence, they
can be best implemented in compiled language like C++. On the other hand,
tasks such as the dynamic configuration of protocol objects and exploring a
number of different scenarios undergo frequent changes as the simulation
proceeds. Hence, they can be best implemented in a flexible and interactive
Shah 31
scripting language like OTcl. Thus, C++ implements the core set of high
performance primitives and the OTcl scripting language express the definition,
configuration and control of the simulation.
4.1.2 C++ - OTcl Linkage
NS supports a compiled class hierarchy in C++ and also similar interpreted
class hierarchy in OTcl. From the user’s perspective, there is a one-to-one
correspondence (see Figure 4.1) between a class in the interpreted hierarchy
and a class in the compiled hierarchy. The root of this class hierarchy is the class
TclObject. Users create new simulator objects through the interpreter. These
objects are instantiated within the interpreter and are closely mirrored by a
corresponding object in the compiled hierarchy. The interpreted class hierarchy
is automatically established through methods defined in class TclClass while
user instantiated objects are mirrored through methods defined in class
TclObject.
Figure 4.1. C++ -- OTcl linkage.
Shah 32
The following classes are mainly responsible for maintaining C++ and OTcl
linkage.
• Class Tcl: This class encapsulates the actual instance of the OTcl
interpreter, and provides methods to access and communicate with that
interpreter. It provides methods for obtaining a reference to Tcl instance,
invoking OTcl procedures through the interpreter, getting or passing the
results to the interpreter, storing and looking up “TclObjects” etc.
• Class TclObject: It is the base class for most of the other classes in the
interpreted and compiled hierarchies. Every object in the class TclObject
is created by the user from within the interpreter and an equivalent
shadow object is created in the compiled hierarchy. The class TclClass
performs this shadowing.
• Class TclClass: This is a pure virtual compiled class. Classes that are
derived from this base class provide two functions: constructing the
interpreted class hierarchy to mirror the compiled class hierarchy- and
providing methods to instantiate new TclObjects.
• Class EmbeddedTcl: The objects in this class are responsible for loading
and evaluating some NS scripts that are required at initialization.
• Class InstVar: This class defines the methods and mechanisms to bind a
C++ member variable in the compiled shadow object to a specified OTcl
instance variable in the equivalent interpreted object. This binding allows
setting or accessing the variable from within the interpreter or compiled
code at all times.
Shah 33
4.1.3 Major Components
Figure 4.2 (Chung and Claypool 2000) shows some major network
components model in NS along with their place in the class hierarchy. The root
of the hierarchy is the TclObject class that is the super class of all OTcl library
objects. NsObject, the direct descendent of the TclObject, is the superclass of all
basic network component objects that handle packets, which may compose
compound network objects such as nodes and links. The basic network
components are further divided into two subclasses, Connector and Classifier,
based on the number of the possible output data paths. The basic network
objects that have only one output data path are under the Connector class, and
switching objects that have possible multiple output data paths are under the
Classifier class.
Figure 4.2. Major components in NS.
Shah 34
4.1.4 Further directions
A complete description of the implementation and architecture of NS2 is
beyond the scope of this thesis. But there are many good sources available for
detailed study of NS2 architecture (“NS2” 1996). Also there are some tutorials
(Chung pg. 34; “Marc Greis” 1998) that may help start running simulations using
NS.
4.2 Why NS2?
NS2 is a publicly available common simulator with support for simulations of
large number of protocols. It provides a very rich infrastructure for developing
new protocols. It also provides the opportunity to study large-scale protocol
interaction in a controlled environment. Moreover, NS software really promotes
extension by users. The fundamental abstraction the software architecture
provides is “programmable composition”. This model expresses simulation
configuration as a program rather than as a static configuration.
NS also has certain disadvantages. It is a large system with a relatively steep
learning curve (Breslau pg. 31). NS’s dual language implementation is proving to
be a barrier to some developers. But increasing awareness among the
researchers along with the other tools like tutorials, manuals and mailing lists
have improved the situation.
Shah 35
4.3 Design and Implementation of Mobile Agent Model
Simulations involving mobile agent or mobile code in general cannot be run
using the standard NS package. An extension is required to include the
necessary features. This section describes the design and implementation of
such an extension.
4.3.1 Assumptions
The following simplifying assumptions are made in order to implement the
mobile agent model.
1. Instead of sending the actual agent code along with data and execution
stack, only a reference to the agent’s OTcl object is sent. Thus, the actual
sizes of agent’s code, data and execution state are required to be set as
parameters of an agent. So it is assumed that all these parameters are
known.
2. It is assumed that the servers, whose services are desired, are known in
advance.
3. It is also assumed that the number of bytes required for request and reply
in each interaction is known.
4. The processing time for an agent (if not explicitly specified for a specific
scenario) and also the time for marshalling and unmarshalling are
assumed to increase linearly with the total size of the agent.
5. The marshalling factor (marshalling time per unit byte) and time required
for an agent’s creation is assumed to be known.
Shah 36
6. The selectivity (Strasser pg. 18) of the mobile agent, defined as a factor by
which the mobile agent reduces the size of the reply by remote
processing, is also assumed to be known (if applicable).
7. No assumption is made about the underlying communication facilities for
migrating agents. Any communication models including RPC, RMI,
CORBA etc. can be utilized. But no such models are currently
implemented in NS.
8. TCP is used as an underlying transport layer protocol. UDP may also be
used here but the above choice is made only for the sake of performance
analysis under reliable conditions.
9. As the principle aim of implementing this model is performance analysis of
mobile agents, no consideration is given to the security matters in mobile
agent systems. Thus, no security overhead is assumed.
10. Although implementation is based upon an entry-point migration
(Brewington pg. 15) (weak migration mainly using IBM’s Aglets API ), it is
assumed to be equally applicable to the study of agent systems with other
types of migration using appropriate values for the model parameters. For
example, while studying strong migration, one can account for the size of
agent’s current execution stack, which can be otherwise considered as
zero for weak migration.
4.3.2 Deciding the Inheritance Structure of the Model
In order to implement the basic behavioral model of mobile agent, the main
objects required are a mobile agent itself and a context or a place where mobile
Shah 37
agents can execute on a given node. Here, context is responsible for creating
mobile agent and also for providing each and every facility required by the agent
like dispatching to other node, loading and processing the incoming agent,
registering, disposing etc. It uses the existing communication facilities for mobile
agent migration. Thus, a context must be implemented on top of the transport
layer facilities. Just like the real world systems, NS applications are implemented
on top of the transport layer agents. Any simulated application is required to
implement the Application interface provided in NS. Thus the mobile agent’s
context is required to implement this Application interface. Though context is
implemented as an application, the mobile agent system model can be easily
utilized for building real world applications on top of it.
Traffic generators Simulated applications
API API
Application/ Traffic/ Exponential
Agent/UDP
Agent/TCP/FullTcp
Application/FTP
Figure 4.3. Application layer in NS.
Shah 38
On the other side, a mobile agent object does not need to fit itself to any
particular level of abstraction. It can be just a simple C++ class derived from the
class TclObject. As stated before, TclObject is the root of all OTcl library objects
and so all the objects that will be accessed by OTcl interpreter, are required to
derive from TclObject. The methods in TclObject are responsible for creating a
shadow object (i.e. corresponding C++ object) for each OTcl object. Mobile
agent’s class (MAgent) also derives from the class TimerHandler in order to
implement timers for various events handling.
4.3.3 Transferring Application-level data in NS
As shown in Figure 4.3 (“NS2” 1996), there are two basic types of
applications in NS: traffic generators and simulated applications. Simulated
applications mainly include FTP and Telnet, while traffic generators mainly
include CBR and Exponential. But all these applications are “virtual” applications,
i.e. they do not actually transfer their own data in the simulator. Thus, as oppose
to the real world systems, there is no actual data transfer between the application
and the transport agent it uses for communication. But in the mobile agent
model, a sending context is required to transfer a mobile agent reference to the
receiving context. So the question is how actual data can be transferred at the
application level.
In order to transmit application-level data in NS, a uniform structure is
provided to pass data among applications and to pass data from applications to
transport agents. It has three components: a representation of a uniform
application-level data unit (ADU), a common interface to pass data between
Shah 39
applications (class Process- base class of Application), and a mechanism to pass
data between applications and transport agents.
ADU is required to pack user’s data into an array that can be then included in
the user data area of the packet by NS transport agents. But as said earlier,
existing NS transport agents do not support user level data. Hence either user
must derive new agents for sending its own data, or some type of wrapper must
be used in between application and the transport layer agent. One such wrapper
used is TcpApp. TcpApp is used for sending user data over TCP. It works as
follows:
Application (Context)
send_data(ADU) process_data(ADU)
send(bytes) recv(bytes)
packets
Application Wrapper(TcpApp)
Agent (FullTcp)
Figure 4.4. Transferring user level data in NS.
Using TCP agents, all the data are delivered in sequence. Thus, a TCP
connection can be seen as a FIFO pipe. Further, applications are provided with
Shah 40
certain up-calls from the transport agents. This includes a recv() call for each
packet along with the number of bytes received. TcpApp provides a buffer for
application data at the sender. It also counts all the bytes received at the
receiver. When receiver gets all the bytes of the current data transmission, as
requested by the user, it gets the data directly from the sender. This direct
communication between the applications again is made possible by using a
common interface provided by class Process. TcpApp in turn can use only
FullTcp or SimpleTcp. Currently it does not support asymmetric agents, i.e.
agents acting only either as a sender or a receiver
Thus, in order to transfer a mobile agent (actually only its reference) from
one context to another one, a context is required to be derived from TcpApp
using it as a wrapper to communicate with the transport layer agents (refer
Figure 4.4). Also TcpApp requires using FullTcp as a transport agent as the only
other option SimpleTcp is actually implemented as a UDP agent.
4.3.4 Design Overview
Figure 4.5 shows the complete hierarchy for class Context implemented as a
child class of TcpApp that in turn derives from Application interface. Thus, the
corresponding OTcl hierarchy name is “Application/TcpApp/Context”. Similarly
MAgent is directly derived from TclObject and hence its corresponding OTcl
name is also “MAgent”.
The following are the basic elements that have been modeled here:
• Context or Place: Context class provides the execution environment
required for agent’s execution including creating any number of agents,
Shah 41
retracting agents from a remote site, disposing agent, registering agent
and actual transferring of agent to another context. By registering agents,
it maintains the list of currently executing agents in a hash table mapped
with the agent’s ID. In order to transfer an agent’s reference, as discussed
before, it needs to define an ADU (Application Data Unit) that derives
from the class AppData. AppData is the base class for all ADUs. The class
thus defined to carry agent’s reference is named as MobileAgentData.
Process
Application
Application/TcpApp
Application/TcpApp/Context
TclObject
TclObject TimerHandler
MAgent
Figure 4.5. Class hierarchies for the model.
Shah 42
• Mobile Agent: MAgent class implements the basic functionalities of mobile
agents like starting the agent after creation or arrival at a context,
dispatching the agent to a remote context, disposing itself after completion
of task, deactivating for a certain period of time, and cloning to make a
copy of itself. It also provides certain abstract methods to be implemented
by the class extending MAgent. These methods are the agent’s entry point
method run(), and certain other provided for agent’s initialization and
actions pertaining to certain conditions like before dispatching, after
arrival, before cloning etc. There are three objects provided to listen to
various events caused by agents viz. mobility, persistency and clone
listeners. Their job is to listen to the corresponding agent events and
invoke the matching actions.
As MAgent class contains some abstract methods, it cannot be instantiated.
To instantiate an agent object, one must extend from the MAgent class. To
facilitate this extension in both C++ and OTcl, a new class named MAgentInst is
created by inheriting from MAgent class. It is actually this class’s object that
shadows with the OTcl class MAgent. It is used to create a default
implementation of all the abstract methods in MAgent class to call the
corresponding method in OTcl and thus allowing extending the MAgent class
directly in OTcl. Figure 4.6 tries to demonstrate the relationship between different
classes mentioned above.
Shah 43
extends extends
contains
contains
contains
contains
contains
extends
MAgent
Context
PersistencyListner
MobilityListner
CloneListner
AppData
MobileAgentData
MAgentInst
TcpApp
Figure 4.6. Class relationship of the model.
4.3.5 C++ and OTcl linkage for the Model
NS has special infrastructure to allow extension in both C++ and OTcl, taking
into consideration the factors like efficiency provided by compiled language and
easy and fast configuration capabilities provided by OTcl. Most of the code in the
mobile agent model has been implemented in C++ for efficiency purposes. The
part requiring less frequent access and the agent configuration is done in OTcl.
Thus, we can say it is a split model between two languages. Hence, a
mechanism is required to link the C++ code to that of interpreter and vice versa.
Shah 44
Each C++ object is required to link to the corresponding OTcl object. For
example as shown in Figure 4.7 C++ Context object’s reference is linked to the
class Application/TcpApp/Context object’s reference (simply a name) in OTcl.
This linking is done by extending the classes like TclObject and TclClass. The
C++ object whose linking with OTcl object is desired must inherit either directly or
otcl class hierarchy
C++ class hierarchy
-o256 context_
TclObject
Application
Application/TcpApp
Application/TcpApp/Context
Process
Context
Application
Application/TcpApp/Context otclShadow Object
Context C++ Object
TclObject
Figure 4.7. C++ and OTcl linkage for the model.
indirectly from TclObject. Also for each such object’s class, a static class
extending TclClass must be defined. This class performs two functions: (1)
construct the interpreted OTcl class hierarchy to mirror the compiled class
hierarchy, using the string pass to the constructor of TclClass
Shah 45
(“Application/TcpApp/Context” here) and (2) instantiate new corresponding
TclObject. The following code shows how this is done in a static class
ContextClass of this model.
/* ContextClass that is responsible for creating a shadow compiled object when
the corresponding interpreted object is instantiated. */
static class ContextClass : public TclClass {
public:
ContextClass() : TclClass("Application/TcpApp/Context") {
} // Passing the corresponding OTcl hierarchy in string form to TclClass
TclObject* create(int argc, const char*const* argv) {
// called when the corresponding OTcl object is instantiated to
// create a new C++ object
return (new Context ( recv_tcp, send_tcp, argv[6]) );
}
} class_context;
This static class is created at the startup of NS and hence is always available
whenever new objects are required to be instantiated. For example a user can
instantiate new context in the simulation script as follows:
set context_ [new Application/TcpApp/Context arg1 arg2 arg3]
# arg2 and arg3 are optional
Also in OTcl code the following constructor is defined.
Application/TcpApp/Context init args {
eval $self next $args
Shah 46
# other initializations
}
Here the interpreter as part of instantiating a new Context object performs
the sequence of actions. Following is a brief overview.
• First step is to obtain a reference handle for the new object from the
TclObject name space, which is acting as name for the object.
• Next is to execute the above constructor for the new object. All such
TclObjects are required to call their super classes in the first line as done
here. This results finally in a call to TclObject constructor at the top, which
is responsible for setting up the shadow object and other bindings.
• At this time the C++ create() method shown above in static ContextClass
is called and instantiates the C++ object.
So this is how to bind C++ and OTcl objects. Sometimes it may also require
binding different variables along with the objects; i.e. the same variable may
require access from both C++ and OTcl. This can be done by establishing a bi-
directional binding such that both of them reads and accesses the same value for
a variable and change in one of them results in the corresponding change in
other one. This binding is established by some special methods in TclObject and
is required to be done in C++ constructor only. The following are some examples
showing how this binding is done for some of the model parameters that can be
set in OTcl .
bind("id_", &id_);
/* establishing binding between C++ integer variable ‘id_’ and OTcl
Shah 47
variable ‘id_’ */
bind("selectivity_", &selectivity);
/* establishing binding between C++ double variable and OTcl
variable */
It is not compulsory to have the same name for both bounded variables but
this helps in better understanding as they represents the same value. This
binding can also be done for bandwidth and time valued variables defined in NS.
The last important matter for OTcl and C++ linkage is support for calling C++
procedures from OTcl and that for calling OTcl procedures from C++. The model
uses both the above types of calls. For every TclObject that is created, NS
establishes the instance procedure cmd{} as a hook to the executing methods
through the compiled shadow object. The procedure cmd{} invokes the method
command() of the shadow object automatically, passing the arguments to cmd{}
as an argument vector to the command() method. The user can invoke the cmd{}
method explicitly specifying the desired operation as the first argument, but more
generally it is invoked implicitly, as if there is an instance procedure of the same
name as the desired operation. Thus, for allowing calls from OTcl to C++, it is
required to implement the command method of TclObject and then to process its
arguments to understand and serve the call. The following example shows how
this can be done for some of the methods provided to interpreter in MAgent
class.
int MAgent::command (int argc, char const *const *argv )
{
Shah 48
Tcl& tcl = Tcl::instance(); // getting interpreter instance
If ( strcmp ( argv[1], "context")==0) {
// if the name of the method invoked in OTcl is “context”
tcl.resultf("%s", getContext()->name());
// pass the context’s name as a result
return TCL_OK; // call is handled OK
}
if(strcmp ( argv[1], "dispatch")==0) {
dispatch(); // makes the corresponding call to C++ method
return TCL_OK;
}
return ( TclObject::command (argc, argv ) );
/* If no command matches then pass the arguments to the parent
command() method. Thus maintaining proper inheritance. */
}
There are several notable features here. The first line inside the method gets
the instance of the OTcl interpreter as contained by Tcl class. This instance is
required for invoking any methods in OTcl and also for passing down the results
of the method invocation in between OTcl and C++. For example note the use of
function tcl.resultf() in the above method. It passes the invocation result back to
interpreter. Similarly results from any OTcl method invoked from inside C++ code
can be obtained using a call to result() without any arguments and such
invocation can be done as follows:
Shah 49
tcl.evalf("%s onCreation", name());
The above method calls the methods onCreation of the object represented
by name() which the mobile agent’s name here.
Although complex, it is very important to understand the linkage between
C++ and OTcl provided by NS because efficient extension of NS needs proper
integration of both of them.
4.3.6 Mobile Agent Model Parameters
The mobile agent model is provided with enough parameters to enable them
reflect the real world’s agent’s behavior. Table 4.1 shows some of the important
parameters (“IBM” pg. 11) associated with a mobile agent.
Table 4.1. Parameters of a Mobile Agent
Id_
Unique ID or name given to a mobile agent. This ID is
unique among all the mobile agent objects currently
existing in the simulation environment.
code_size_
data_size_
Represents the size of the code and data of a mobile
agent respectively (in bytes).
status_size
Represents the size of the status stack of the agent
during migration. This will be required only for strong
migration, as agents following weak migration do not
take the current execution stack with them (in bytes).
Shah 50
Table 4.1. Parameters of a Mobile Agent, continued
Size_ Total size of the agent migrating from one context to
another (in bytes).
selectivity_ Factor by which the mobile agent reduces the size of
the reply by remote processing
State_ Current state of the agent i.e. whether it is IDLE,
ACTIVE, MOBILE or TERMINATING etc.
Node_ Name of the current node of execution
homenode_ Name of the originating node
context_ A reference of the current context in which agent is
executing
m_factor_ Marshalling and unmarshalling factor defined as time
required for marshalling the unit byte of data.
create_delay_ Agent’s creation time
process_delay_ Agent’s processing time. It is assumed to be linearly
proportional to the agent’s size.
launch_delay_ The time taken by the agent while migrating to a
destination node for packing and unpacking its data,
state and code. It is in option to parameter m_factor_
and should not be set if m_factor_ is used.
Shah 51
The only parameters associated with a context (“IBM” pg. 11) are shown in
Table 4.2.
Table 4.2. Parameters of a Context
node_ Name of the node on which the context exists.
enable_ Flag use to set whether the context is enable or disable.
agent_list_
Reference to a hash table use to store references of all the
mobile agents currently executing in the context. The hash table
maps an ADU (MobileAgentData) object to the agent’s ID.
4.3.5 Mobile Agent Methods
The C++ class MAgent models the basic functionalities of a mobile agent like
its starting, dispatching, cloning, deactivation, etc. Table 4.3 shows the methods
(again prototype used here is inspired from IBM Aglets API) it implements and
that should not be over-ridden by the derived class:
Shah 52
Table 4.3. Methods Implemented in MAgent Class
void dispatch() Allows an agent to dispatch itself to the next
destination. The destination is taken from
the agent’s inventory list.
void dispatch(const char* ) Overloaded method to allow agent’s
dispatch to a particular context destination. It
can be used when inventory list is not given
to the agent.
void deactivate( long ) In real world the mobile agent is stored for
that time on permanent storage. But here no
actual storage is done. Agent just sleeps for
the given duration to simulate its
deactivation.
void dispose() It just deletes the current agent object and
also makes sure that it is removed from the
agent’s list maintained by the context.
MAgent* clone() Creates an exact copy of itself including the
copy all the data members.
bool is_active() Checks if the agent is currently in ACTIVE
state or not.
Shah 53
Table 4.3 Methods Implemented in MAgent Class, continued
void addMobilityListener ()
void addPersistencyListener()
void addCloneListener()
Adds respective listeners that will listen to
corresponding activities of the agent
void removeMobilityListener()
void removePersistencyListener()
void removeCloneListener()
Removes the corresponding listeners that
are no more required.
void startCreatedAgent (const
char*, Context*, int )
void startArrivedAgent (Context* )
void startRetractedAgent
(Context* )
Starts the agent after the corresponding
events like creation, arrival to a new context
and retraction from a remote context
respectively.
The following functions are also defined by the class MAgent, but are
intended to be over-ridden by the classes deriving from MAgent.
• onCreation() – User can over ride this method if it is requires to initialize
the mobile agent with specific information. This over-ridding can be done
either in C++ or in OTcl as discussed above.
Shah 54
• onDisposing() – As name suggest this method is called when an agent is
about to dispose off. Override this method if it is required to do some clean
up before the agent is deleted.
• run() – This is the main entry point method for the agent. The code written
in this method actually characterizes the agent. This is the method
invoked by the context when an agent is created or migrated to a new
node. Unlike all other methods mentioned above, it is compulsory to
override this method as it determines the task of your agent.
4.3.6 Mobile Agent’s Event Listeners
As shown in Figure 4.6, a mobile agent object can have three listeners
depending on user’s requirement. User can add or remove them dynamically
using methods shown in Table 4.3 like addMobilityListener(),
removeMobilityListener() etc. This listeners also provide certain methods that
user can override in order to make the mobile agent do certain actions at a
certain time. Their job is to listen to the current state of the mobile agent and
whenever the state changes, invoke a corresponding method. Some of this
methods includes:
• onArrival() - The mobility listener object calls this method whenever the
mobile agent arrives at a new context. In our model the overhead of agent
loading can be accounted here.
• onDispatching() and onReverting() – They are also triggered by the
mobility listener object when the corresponding event happens i.e. before
Shah 55
dispatching of the agent to a new context and before reverting an agent
from a remote context to the current context.
• onCloning() – The clone listener object invokes this method just before the
agent is required to clone.
• onClone() and onCloned() – They are also triggered by the clone listener
object for initialization of the newly created object and for implementing
any functions required to be done on agent that has undergone cloning
respectively.
4.3.7 Purpose and Functioning of MAgentInst class
The class MAgentInst inherits from MAgent. But this class does not add any
functionality to the mobile agent. It just provides a default behavior for all the
abstract methods of the base class and that behavior is to invoke the
corresponding methods of OTcl. Thus the purpose of MAgentInst class is to
provide a user an OTcl interface for the abstract methods so that he can
instantiate mobile agent objects and override whatever methods he needs,
directly from OTcl without extending MAgent class in C++. This plays a very
important role in providing the flexibility of implementing the agent’s behavior in
either C++ or OTcl or in both.
Following is an example of how this binding is done between C++ and OTcl.
Here the abstract run() method, which is entry point method for an agent is
implemented. In the implementation the corresponding run() method of OTcl
interpreter is invoked using Tcl instance.
Shah 56
// "Bring-back-to-life" method
// context - reference to context in which the current agent is executing
void MAgentInst :: run ( Context* context)
{
Tcl& tcl = Tcl::instance(); // getting the OTcl interpreter instance
// Interpreter instance is necessary for any calls made from C++ to OTcl
tcl.evalf ("%s run %s", name(), context->name());
// calling the corresponding run() method in OTcl of class represented by
// name() i.e. the current agent and context’s name as an argument
}
It is important to note here that if the user is not extending MAgent class in
C++, he is required to implement the run() method in OTcl. This is because in
OTcl the “run” method is not defined. This is not the case with all the other
methods available for overriding in OTcl as their default definition is provided in
OTcl..
4.3.8 Methods Implemented in class Context
Context provides services to the mobile agents and also maintains a hash
table of agents currently registered with it. The context is responsible for actual
transfer of the agents as well as agent’s creation. Table 4.4 shows the prototype
of the important methods implemented along with their functions.
Shah 57
Table 4.4. Methods implemented in Context class
void process_data(int, AppData* ) It over-rides the behaviour of TcpApp and is
the principle method for processing the
incoming agent. It retrieves the agent’s
reference stored in the MobileAgentData
and loads and starts the agent by calling
agent’s startArrivedAgent() method.
void retractAgent(const char*) It is used to draw back the agent from a
remote site
void registerAgent(MAgent*, int) As name suggests, it is used to initialize the
agent and register in the agent’s table.
void disposeAgent (int) It just erases the agent from the table.
void startAgent (const char* , int) Procedure that initializes the agent right
after its creation and stores it in hash table.
void move (int id, int size) Moves the agent represented by key “id”
with a size given by “size” to next destination
void move(int id, const char*
context, int size)
Moves the agent represented by key “id”
with a size given by “size” to the destination
context given by “context”
void registerAgent(MAgent*, int) Inserts the agent into the hash table with
corresponding key.
Shah 58
4.3.9 Modeling of Agent’s Timer
The modeling of the time consumption by various agent actions such as
creation, dispatch and processing is done by using the agent’s timer
implemented in C++. In order to implement this timer MAgent class needs to
extend the class TimerHandler. This requires the implementation of the abstract
method of TimerHandler class called expire(), which will be invoked on the
expiration of the timeout or scheduled period.
The actual time required for the above agent actions can be set as its
parameters namely create_delay_, process_delay and launch_delay_. Instead of
launch_delay_ user can also set a marshalling factor m_factor_ from which the
total launching delay can be calculated. This can be done as follows:
Launching delay includes the time required for packing (marshalling) the
agent’s code, data and state together at the sender’s side and that of unpacking
(unmarshalling) and loading it at the receiver’s side. The marshalling factor
(m_factor_) is given as the marshalling (or unmarshalling) time per unit byte of
data and is assumed to be linearly proportional to the total data to be marshaled.
Thus, the launching delay can be given as
launch_delay_ = 2* m_factor_ * size_ 4.1
Here, multiplication factor of ‘2’ accounts for both marshalling and
unmarshalling of total size of the agent given by ‘size_’. Also the total size is
calculated as
size_ = code_size_ + data_size_ + status_size_
+ (1- selectivity_)* rep_size_ 4.2
Shah 59
The parameter ‘rep_size_’ represents the result data that may be produced
without any remote processing and selectivity_ is the factor by which this result
data can be reduced using remote processing.
Whenever an agent is about to undergo any of the above actions i.e.
creation, dispatch or processing, all the further agent actions are rescheduled by
the time given by the corresponding action’s parameter. When the schedule time
expires, the timer invokes the expire() method which implements the agent‘s next
execution step depending on its current state. The expire() method as
implemented in C++ class MAgent is given next.
/* Method expire() of class MAgent defined in ~/mobile agents/MAgent.cc
It is invoked when the rescheduled time expires */
void MAgent::expire(Event* e) {
switch(state_) {
case MOBILE: // If agent is in MOBILE state mean it is required to
// dispatch and so call move facility of the context
if(dst_context_)
context_->move(id_,dst_context_,size());
else
context_->move(id_, size());
break;
case ACTIVE: // Timeout after considering processing time
// invoke the run() method for the agent
run(context_);
Shah 60
break;
case IDLE: // If agent is idle initially, make it active and call run()
state_ = ACTIVE;
run(context_);
break;
case DEACTIVATING:
// if the agent is deactivated, make it active now..
state_= ACTIVE;
if(p_listener_){
p_listener_->state_ = ACTIVE;
p_listener_->resched(0);
}
default:
printf("\nMAgent::Illegal mobile agent's state\n");
} // end of switch statement
} // end of expire()
Shah 61
4.3.10 OTcl Interface for the mobile agent model
OTcl interface consists of all the procedures and variables available through
the OTcl interpreter. The procedure thus includes the instance procedure written
in OTcl as well as procedures available to the OTcl interface through command()
method implemented in C++ as discussed in section 4.3.5. Similarly the variables
or parameters available to the user are either those defined in OTcl alone or
those bound between C++ and OTcl using TclObject’s bind() method. The
complete list of such parameters and procedures is given in the Appendix - the
User’s Guide to the Mobile Agent Model.
Shah 62
4.4 Adding mobile agent model to NS package
Once the model is implemented the question of where to add this code in
existing NS package may arise. The directory structure of NS in the current
version of NS (ns-2.1b9a) is shown in Figure 4.8. Among the sub-directories of
ns-allinone, ns-2 is the place that has all of the simulator implementations (either
in C++ or in OTcl), validation test OTcl scripts and example OTcl scripts. Within
this directory, all OTcl codes and test/example scripts are located under a sub-
directory called tcl. Similarly all the C++ code, which implements event
scheduler, basic network component object classes, etc. are located in the
corresponding subdirectories. For example the directory app consists of
implementation of all classes modeling the application layer eg. Application, FTP,
Telnet etc. and directory tcp consists of classes implementing different flavors of
Tcp protocol like Reno, Tahoe etc. All the OTcl code of the basic network
components required for simulation is implemented in sub-directory lib of tcl
directory. The OTcl code for other components is implemented in separate
directories for each model, just like C++. For example, subdirectory mcast
contains implementation of the OTcl code for modeling multicast simulation.
Thus, deciding the place for the mobile agent model is straightforward. All the
C++ classes are contained in a directory named mobile agents and that directory
is placed along with other directories containing C++ code. This is shown in
Figure 4.6 with a dotted line. Similarly all the OTcl code is contained in a similar
directory that in turn is placed as a sub-directory of tcl (Figure 4.8).
Shah 63
ex
Tcl , Tk ,Nam and other packages
tcl Makefile.in other C++ code
mobile agents(C++)
apps
TclclOtclns-2
tcp
test lib mcast
mobile agents(OTcl)
other OTcl code
ns-allinone
Figure 4.8. Adding mobile agent model to NS.
The final step for adding a new model to NS is to edit the ‘Makefile.in’ to add
the new-implemented files for compilation and linking with other files. This mainly
includes addition of object files like MAgent.o, MAgentInst.o, Context.o, and
MobilityListener.o etc. to the object file list. Before re-compiling the modified NS it
may be required to re-configure and to execute “make depend”.
Shah 64
4.5 Model Interactions
In order to understand the working of the model lets consider a simple
scenario consisting of two contexts context1_ and context2_ deployed on two
different nodes node1 and node2. This can be done as follows.
set context1_ [new Application/TcpApp/Context $send1 $recv1 $node1]
$context1_ start
set context2_ [new Application/TcpApp/Context $send2 $recv2 $node2]
$context2_ start
The contexts thus started are ready to create as well as accommodate
mobile agents. So next at a certain simulation time, a mobile agent is created
and started at context1. Mobile agent’s parameters can also be set here. If any of
the parameters are not set, it will take the default parameters defined in
~/tcl/lib/ns-default.tcl. The commands required are as follows:
set agent_ [new MobileAgent] ;# creates agent instance
$agent_ set code_size_ 5000 ;# setting agent’s code size (in bytes)
$agent_ set data_size_ 1000 ;# setting agent’s data size (in bytes)
$agent set m_factor_ 0.000001 ;# setting marshalling factor (sec/bytes)
$agent set create_delay 0.01 ;# agent’s creation time (in sec)
$agent set process_delay 0.1 ;# agent’s processing time (in sec)
$agent_ set selectivity_ 0.6 ;# setting agent’s selectivity
$ns_ at 5.0 “$context1_ start-agent $agent_ “
# create and start agent in context1 at simulation time of 5 secs
Shah 65
Note here that class “MobileAgent” of OTcl corresponds to class “MAgent” of
C++ (actually class “MAgentInst” as described in section 4.3.7). Also it is required
to implement the run() method to define agent’s behavior. For example, to make
agent dispatch itself from its current context to the other context, the run()
method can be implemented as follows:
MobileAgent instproc run { context } {
global context1 context2 node1 node2
# getting global variables from the simulation script
$self instvar node_ homenode_
# getting instance variables of MobileAgent class
if { $node == $homenode_ } {
# if current node is the homenode of the mobile agent
$context connect-to $context2
# connecting current context to the destination context
$self dispatch
# invoking its instance procedure (implemented in C++)
# to enable agent’s transfer to another context
} else {
# agent reaches at its destination
puts “ Hey! I have reached my destination”
} ;# end of if-else
} ;# end of instproc run()
Shah 66
1 2
11
4 10
3 7
5 6
9 8
User
OTcl Interpreter
Mobile Agent
(agent_)
Context 1
(context1_)Other ns modules
Context 2
(context2_)
Figure 4.9. Model interactions for an example scenario.
Figure 4.9 shows the series of interactions that will occur when the simulation
script is executed.2 The action starts at simulation time of 5 seconds with a call
to procedure start-agent in OTcl implementation of Context class represented by
OTcl interpreter in the figure. The numbering is done in the sequence of
interactions and the corresponding name of the procedure called is given in
Table 4.5.proce
2 The code given above is not a full simulation script, as it does not include creating simulator instance, nodes, links etc.
Shah 67
Table 4.5. Sequence of Interactions
Interaction Seq. #
Procedure Called
1 start-agent()
2 createAgent()
3 startCreatedAgent()
4 run()
5 dispatch()
6 move()
7 send()
8 process-data()
9 startArrivedAgent()
10 run()
11 Return to call-1 for start-agent()
Finally, after executing the interpreter’s run() method (Step 10) the control
returns back to the user’s script from where the command start-agent was
invoked. The steps 5 through 10 will be repeated as many times the agent
dispatches itself from one context to another. Thus user only needs to implement
run() method and optionally onCreation() and other methods invoked by the
listeners and all the implemented methods will be invoked at the corresponding
time. By doing so, any complex behavior of a mobile agent can be easily
implemented. Please note here that the listeners are not shown for simplicity.
Shah 68
4.6 Problems encountered and their work-around
Although the mobile agent model designed and implemented above worked
well for the simple scenario described above, some problems were faced in
simulating complex scenarios. This is not due to any design or implementation
problem in this model but is because of certain bugs in NS, which are still
required to be fixed. In this section, these problems and the work-arounds are
discussed.
All these problems are caused by a transport layer agent FullTcp
implemented in basic NS2. FullTcp extends the functionality of regular tcp agent
Agent/TCP. Unlike other agents, it is designed to provide a bi-directional
connection, in which the transport agent can send and receive packets
simultaneously. But in its actual implementation, it seems to be assumed that
though they have capability to do the job of sender and receiver, a particular
agent either sends or receives, but not both. Now the mobile agent model
requires that the context must be able to send and receive agent simultaneously.
Also, as the Context class is derived from TcpApp class and as the TcpApp class
supports only FullTcp, it is compulsory to use FullTcp as a transport layer agent.
After a notable pain of debugging the complex FullTcp code, it was decided to
rather go for a speedy work-around. This is as follows:
The Application class, which is the base class for Context, contains a pointer
to only one transport layer agent. Thus, the context object can have only one
agent that can either send or receive but not both due to the problems in FullTcp.
Shah 69
So the code of the Application class is modified to accommodate reference to
two new agents, one for receiving and the other for delivering the packets. This
modification is backward compatible i.e. one can still use an application with only
one agent as before and no change in OTcl interface is required. The following is
the example code showing how this is done.
// Part of command() method of the Application class (file ~apps/app.cc)
if (strcmp(argv[1], "agent") == 0) {
tcl.resultf("%s", agent_->name());
return (TCL_OK);
} // to send back the name of the normal agent as was used before
// the following code is added to occupy two different agents
if (strcmp(argv[1], "recv_agent") == 0) {
tcl.resultf("%s", recv_agent_->name());
return (TCL_OK);
} // to send back the name of the agent appointed for receiving packets
if (strcmp(argv[1], "send_agent") == 0) {
tcl.resultf("%s", send_agent_->name());
return (TCL_OK);
} // to send back the name of the agent appointed for sending packets
The corresponding modification is also done in TcpApp to support two
additional agents. The constructor of TcpApp class is overloaded to add the
following constructor:
/* Overloaded TcpApp class constructor (in file ~webcache/tcpapp.cc)
Shah 70
This constructor is defined to support the mobile agent model and attaches
the two agents received from the context */
TcpApp::TcpApp(Agent *recv_tcp, Agent *send_tcp) :
Application(), curdata_(0), curbytes_(0)
{
agent_= NULL;
recv_agent_ = recv_tcp; // attaches the recv_agent to itself
recv_agent_->attachApp(this); // attaches itself to the recv_agent
send_agent_ = send_tcp;
send_agent_->attachApp(this);
}
These modifications thus solved the problem of bi-directional connection. But
it should be noted here that though this work-around did not cause any problem
in existing NS (as proved by the successful execution of the NS validation tests
after the modification), it is only temporary until the bug in FullTcp is solved.
There is one more problem to be solved with FullTcp in wired-cum wireless
scenario. When one of the two communicating FullTcp agents is a mobile node
and the other is a fixed node, the transmission of packets does not work. The
main problem encountered may be the additional bytes added to the packets at
the lower network or physical layer in heterogeneous networks. This problem is
also not solved as yet, but its work-around was found in the NS mailing list. This
is not believed to be working perfectly as found from various simulation results
and will be pointed out later in chapter 5.
Shah 71
4.7 Validating the Mobile Agent Model
One of the most difficult problems facing a simulation analyst is trying to
determine whether a simulation model is an accurate representation of the actual
system being studied, i.e., whether the model is valid. Thus, the first step in the
simulation analysis by a new model is its validation. Various techniques can be
employed for validating a model. The most definitive technique is to establish that
the model’s output data closely resemble the output data that would be obtained
from the actual system. But sometimes it is difficult to get such data from the
actual system. Hence other less difficult approaches must be employed. One of
these is to recognize the parameters of a system and describe their relations in
the form of a mathematical model that can be further used to check the
effectiveness of the simulation model. In this section, we have shown the
effectiveness of the mobile agent model using a simple mathematical model
inspired by work done in (Strasser pg. 18).
The authors in (Strasser pg. 18) derived the equations for execution time
requirement and network load for a simple scenario consisting of two nodes and
a single interaction using mobile agents. We have made certain modifications in
these equations for taking into account the following two differences between the
mathematical model in (Strasser pg. 18) and the simulation model considered in
this thesis.
1. Agent’s code caching is not considered in this thesis. Thus the entire
agent code is transmitted along with its data and execution stack. On the
Shah 72
other side, in (Strasser pg. 18), agent’s code is transmitted only if it is not
available at the receiving node.
2. This thesis also does not consider the optimization of sending only the
results back to the agent’s home node instead of entire agent as is
considered in (Strasser pg. 18).
Thus the scenario considered here consists of a client at node n1 that
launches an agent A to a server at node n2. This agent may perform some
filtration of the results by remote processing and finally returns back to the
requesting node with the results. The agent consists of Bcode bytes of code, Bdata
bytes of data and Bstate bytes of execution state and is described by the triple BA
= (Bcode, Bdata, Bstate). The size of the reply from the server is Brep and the
selectivity of the agent is given by σ. Thus the actual size of the results that agent
is required to carry after remote processing is (1-σ) Brep.
Thus, the total network load for the migration of an agent A from node n1 to
node n2 and then back from node n2 to node n1 along with filtered results can be
given as:
BMR = Bcode + Bdata + Bstate + (1-σ) Brep 4.3
Further, δ denotes the delay and τ denotes the throughput of the link
between nodes n1 and n2 and also µ represents the marshalling overhead
(represented by m_factor_ in the simulation model of this thesis). Thus the
execution time for a single agent migration from node n1 to node n2 will be
TMig = δ + [(1 / τ) + 2µ] ( Bcode + Bdata + Bstate)
Shah 73
Similarly, the total execution time for the entire agent task, neglecting any
other processing time, can be given as:
TMR = TMig + δ + [ (1/ τ) + 2µ ] BMR 4.4
The above equation represents the mathematical model and is further used
for validation of the simulation model. The input parameters to both the
simulation model and the above equation are kept same and the output data are
compared (see Figure 4.10) (Law and Kelton 2000). The same input data helps
to get a statistically more precise comparison. This approach is called the
correlated inspection approach (Law pg. 74).
Same
Compare
Input Parameters
Input Parameters
MathematicalModel
Simulation Model
Output Data
Output Data
Figure 4.10 Validation of the Mobile agent Model.
The parameters used for feeding both simulation and mathematical model
are given in Table 4.6. It is important to note here that though throughput τ is
considered to be constant in above equations, it varies notably during
Shah 74
simulation along with the amount of data to be transmitted during each
interaction. This is because the data transmitted during simulation is much
less comparing to the bandwidth of the link (1 Mb) and hence more
transmission of data results in higher throughput. This variation in throughput
along with the change in selectivity of the agent is shown in Figure 4.11. As
the selectivity of the agent increases, the number of bytes required
transmitting decreases and hence the throughput also decreases. Due to this
variation in throughput, its mean value that is calculated over all the
interactions is used in the above equations.
Table 4.6 Parameter Values used for Validation
Parameters Values
code_size_ 10000 bytes
data_size_ 5000 bytes
status_size_ 0 bytes
req_size 1000 bytes
Average Throughput
80,976 bytes/secor 647.81 Kbps
Latency 20 ms
Shah 75
660006800070000720007400076000780008000082000840008600088000
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Selectivity of the Agent
Thro
ughp
ut (B
ytes
/sec
)
Figure 4.11. Variation of throughput with agent’s selectivity
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Selectivity of the Agent
Tim
e R
equi
red
for t
he In
tera
ctio
n
Simulation Output Mathematical Output
Figure 4.12. Comparison of mathematical and simulation model.
Shah 76
Simulation is done by varying the selectivity of the mobile agent from 0 to 1
at a fixed reply size of 20,000 bytes and the total time required for the interaction
is measured. Also substitution of similar parameters in equation 4.4 gives the
corresponding time for the mathematical model. Figure 4.12 shows the results
obtained from both the models. The direct comparison based on the graph shows
the resemblance between the two models. The mean of the differences between
the outputs of two models is calculated in Table 4.7. The percentage mean-
difference from the mathematical model thus obtained is about 4.4%. This is
satisfactory considering notable variations in throughput experienced during
simulation along with the variation in number of bytes to be transmitted (see
Figure 4.11). Thus, the simulation model precisely corresponds to the
mathematical model and hence can be effective in the preliminary studies of the
mobile agent technology.
Shah 77
Table 4.7. Output from Models and their Differences
Selectivity Simulation Model
Output (Xi) Mathematical Model
Output (Yi) Difference Zi = Xi - Yi
0 0.57737602 0.637467 -0.06009098
0.1 0.56009602 0.612768 -0.05267198
0.2 0.54281602 0.58807 -0.04525398
0.3 0.52585602 0.563371 -0.03751498
0.4 0.50857602 0.538672 -0.03009598
0.5 0.49129602 0.513974 -0.02267798
0.6 0.47401602 0.489275 -0.01525898
0.7 0.45705602 0.464576 -0.00751998
0.8 0.43976802 0.439877 -0.00010898
0.9 0.42248802 0.415179 0.00730902
1 0.40521602 0.39048 0.01473602
Mean 0.4913236 (Xmean) 0.5139735 (Ymean) -0.0226498 (Zmean)
Percentage Difference
= |(Zmean/Ymean)* 100| 4.406820
The exact validation of the model might be possible using the actual system
data rather than that from mathematical model. But this was difficult to measure
due to the unavailability of the resources and limited scope of this research. This
can be considered as a part of the future work in further development of this
simulation model.
Shah 78
CHAPTER-5
Simulating Wireless Applications Using Mobile Agent Model
The Network Simulator NS2 along with the extension of mobile
agent as described in the previous chapter is used to simulate certain basic
wireless applications where the usage of the mobile agents is believed to be
beneficial. The list of applications where the mobile agent paradigm may be used
is given in section 3.3 of chapter 3. Out of all those applications, this study
concentrates on the deployment of the mobile agent paradigm in information
retrieval and also in middleware for providing service adaptation to a mobile
device. The information retrieval application is studied for two different scenarios
(section 5.1 and 5.2 respectively), both of which consist of a number of servers
and a client looking for certain set of information. A brief study of the
performance of mobile agent in the middleware is described in section 5.3
5.1 Information Retrieval- Scenario 1
The first scenario consists of a finite number of web servers (for example of
different virtual enterprises) connected to the Internet and a mobile user (or
client) looking for specific information (may be a particular product) from any one
of these servers (Jain pg. 6). Figure 5.1 represents this scenario. It is assumed
here that the user does not know on what server the information he is looking for
is available. Each server is assigned a certain probability of having the requested
Shah 79
information. Thus, the user requires requesting each server serially until the
information is found.
The scenario is simulated using both client-server and mobile agent
paradigm. In the client-server paradigm, the user device is required to pass the
messages over the wireless link and through the base station on to the different
Server 1
Server 2 Mobile User Base Station
Server 3
Server n
Figure 5.1. Information retrieval - scenario 1.
servers. The result is also returned through the same path. This interaction is
repeated with as many servers as required till the information is obtained. In
mobile agent paradigm, the user device launches an agent with enough
Shah 80
intelligence to carry on the search for the required information on different
servers until the task is completed, when the agent returns to the originating
device with results. Thus, the agent is required to be transmitted over wireless
link only twice. Figure 5.2 shows the picture representing this scenario as
obtained from the Network Animator (“NAM” 1996). The current version of NAM
does not support the visualization of the mobile node (user device) in wired-cum-
wireless scenarios. Hence, it cannot be seen in the figure. The base station node
(represented by number 8) is connected to the gateway (number 0), which in turn
is connected to all other servers.
Figure 5.2. Visualization of scenario 1 using NAM.
The unreliability of the wireless network is represented by packet loss during
transmission through the wireless channel. This packet loss is simulated using
Shah 81
the error model provided in NS. The error model can be introduced in a mobile
node as follows:
# Configure the mobile node to contain the error module
$ns_ node-config -OutgoingErrProc UniformErr
# OutgoingErrProc corrupts packets going out from the wireless channel
# corresponding to a node
# procedure UniformErr must create and return an error model instance.
proc UniformErr { } {
global opt
set err [new ErrorModel] ;# new instance of error model
$err unit packet ;# error introduction in unit of packet
set rng [new RNG]
$rng seed 1
$err ranvar [new RandomVariable/Uniform]
# Setting random variable and not using the default one
$err set rate_ $opt(err_rate)
# Setting rate of error introduction
return $err ;# returning the model instance
}
The probability of having required information on a particular server is
assigned by generating uniformly distributed random numbers ranging from 0 to
1. Further, another random number generator is used to simulate the finding of
the information based on the assigned probability. This is done as follows:
Shah 82
# creating an instance of random number generator and seeding it
set rng [new RNG]
$rng seed 12345
# creating a uniformly distributed random variable that uses the RNG
set u [new RandomVariable/Uniform]
$u use-rng $rng
$u set min_ 0
$u set max_ 1
# setting random probabilities between 0 and 1 to each server
for {set i 0} {$i<$num_wired_nodes} {incr i} {
set prob($i) [$u value]
}
# The following procedure simulates the finding of the information at a server
proc is_info_found {count_} {
global prob
set rng [new RNG]
$rng seed 67890
set v [new RandomVariable/Uniform]
$v use-rng $rng
$v set min_ 0
$v set max_ 1
set val [$v value]
if { $val < $prob($count_) } {
Shah 83
return 1
} else {
return 0
}
}
In mobile agent method, “run()” method is required to implement the agent’s
behavior of launching to different servers in one by one until the information
required is found. This is shown in the following code.
# run {} method in the simulation script for scenario 1
MAgent instproc run {c} {
$self instvar context_ homenode_ job_done_
global ns_ num_wired_nodes count_ latency opt context
set node_ [$self node] ;# current node visited
set context_ $c ;# current context of execution
if {$job_done_ == 0 } { ;# if task is not completed yet
if { $node_ == $homenode_ } { ;# if current node is homenode
if { $count_ == 0 } { ;# if agent is just starting..
set dstcontext $context([expr $count_+1])
$context_ connect-to $dstcontext
$self dispatch
} else { ;# else agent is returned back without
record ;# any results
$self dispose ;# disposing itself
Shah 84
}
} else {
set job_done_ [is_info_found $count_]
set count_ [expr $count_ +1]
# if information not found dispatch to next node else dispatch to
# home node
if { $job_done_ == 0 && $count_ < $num_wired_nodes} {
set dstcontext $context([expr $count_+1])
} else {
set dstcontext $context(0)
}
$context_ connect-to $dstcontext
$self dispatch
}
} else { ;# if information is found and agent
record ;# returned to home node
$self dispose
return
} ;# end of outer if-else
} ;# end of run()
In client-server method, the implementation of this scenario is a bit more
complex. This is done mainly by writing small procedures for sending request
and reply. The receipt of a request or reply is notified by the invocation of
Shah 85
procedure passed as an argument to the TcpApp application while sending the
data. This procedure in turn can be implemented to process the request or reply.
For example a client can send a request to any server as follows:
proc send-request { } {
global ns_ server_rcv user_snd count_ user_app server_app opt
$ns_ connect $user_snd $server_rcv($count_)
$server_rcv($count_) listen
$user_app connect $server_app($count_)
$user_app send $opt(req_size) "process-request"
}
This will result in the invocation of the procedure named “process-request”
after the transmission of number of bytes given by opt(req_size) is done. Further,
this procedure can be implemented as below.
proc process-request { } {
puts "Replying now...."
send-reply
}
The procedure send-reply similarly sends required bytes and provides a
name of the procedure to be invoke (process-reply). In “process-reply” client will
check whether the required information is obtained or not and if not, it will make
request to next available server.
This scenario is studied by varying different network as well as agent’s
parameters to evaluate the performance of mobile agent paradigm in different
Shah 86
situations and also to compare it with the corresponding client-server paradigm.
On the other hand some parameters are kept constant in all the cases. For
example, size of the request and reply for a single interaction with the server is
fixed at 5000 bytes each, while the data size and selectivity of the agent is fixed
to 5000 and zero respectively. The selectivity value here suggests that the
possibility of remote filtration of the results by the agent is not considered.
Similarly the link parameters like bandwidth and delay are kept the same in all
cases for both the wired (2 MB, 10ms) and wireless connections (500 KB,
10ms). The different cases thus studied are described in the following
subsections along with their results.
5.1.1 Ideal Conditions for Mobile agent Systems with No Overhead
The first case considers the ideal conditions for mobile agent system, which
assumes no other overhead caused by the use of agent paradigm. Thus all the
overhead parameters like time for agent’s creation (create_delay_) and agent’s
marshalling and unmarshalling time (m_factor_) are set to zero, i.e. their default
values. Also the total size of the agent is set equal to the size of request and
reply for the corresponding client-server paradigm. Thus, no size overhead is
considered. In this simple case, the total time required by the query from the
mobile user is measured at different wireless network conditions by varying the
probability of packet loss from 0 to 0.5 on the wireless link. Simulation does not
work at packet loss rate higher than 0.5 because of the retransmission problems
encountered as a result of modification in FullTcp as described in section 4.7.
Shah 87
Figure 5.3. Performance comparison- ideal conditions
Figure 5.4. Performance ratio mobile-agent/client-server.
Shah 88
The results obtained from both the methods are shown in Figure 5.3. It can
be seen from the figure that the results are exactly what one would expect. At low
packet loss rate the performance by both methods is similar. But as the packet
loss rate increases, the performance of the client-server method degrades
exponentially while that of mobile agent method is not affected much. This is
because the mobile agent method does the least use of the wireless link in
compare to client-server method. Further at some higher packet loss rate, the
time required for agent paradigm also increases exponentially as the number of
re-transmissions required increases rapidly. Finally, after a certain point no more
transmission is possible and all the packets are dropped. Figure 5.4 tries to show
the same conditions in a different perspective in the form of performance ratio of
mobile agent to client-server technology. It can be seen that the performance
ratio rapidly increases initially along with loss in wireless networks and finally
tries to stabilize after a certain point.
These results clearly show the effectiveness of the mobile agents in this type
of applications. But the actual deployment of mobile agents cannot provide such
an ideal performance mainly because of the several overheads.
5.1.2 Effect of the Mobile Agent’s Size Overhead
Mobile agent’s size may play a considerable role in degrading its
performance especially on a low bandwidth connection typical of wireless
networks. Hence it is important to study the agent’s performance in terms of its
varying size. In this case the size of the agent is varied in multiple of the original
size used in the first case. Again the parameter measured is the time required for
Shah 89
completion of the query. The client’s request and reply sizes are not changed. As
the size of the agent’s code increases, the processing time for the agent on the
remote server may also increase. It is assumed that this processing time is
directly proportional to the size of the agent’s code. Figure 5.5 shows the results
in this case with the agent’s size varying from 5000 bytes to 25,000 bytes and
packet loss rate is fixed at 0.15.
It can be seen from the figure that the performance benefits of mobile agents
is substantial only up to certain agent’s code size (around 15 KB) and after that
the client-server method shows much better performance. This shows the severe
impact of agent’s size on its performance. The client-server method is not
affected here as its request or reply sizes are not changed and hence gives a
constant time.
Figure 5.5. Performance comparisons with variable agent code size.
Shah 90
5.1.3 Effect of Creation and Marshalling/Serialization Overhead
Another important factor in degrading the performance of a mobile agent is
the overhead caused by the time required for agent’s creation and the time
required for agent’s packing of code, data and status at the dispatching node and
unpacking at the receiving node. Both depend on the actual implementation of
the mobile agent system and also the type and size of agent’s data. For example,
agent’s creation time will be different for a mobile agent system forking a new
process (or may be an interpreter) for each agent created compare to one who
uses an existing process or just need to fork a new thread. This creation time for
different agent systems is measured in the previous experiments (Dikaiakos pg.
18) and is available. In the similar way, agent’s packing time will be different for
those using marshalling compared to some java-based systems using
serialization. The marshalling overhead further will increase with the overall size
of the agent. The factor representing this overhead (m_factor_) is assumed to be
linearly proportional to the size. The marshalling factor further also depends on
the type of data to be packed (mainly for serialization). For measuring this factor
for certain Java data types, a class called SerializeTest (“SerializeTest” 1998) is
used. This is a simple code written in java to measure the memory and time
requirements for serializing different Java data types. With the help of this
program, m_factor_ for a vector of integers is determined.
Shah 91
Figure 5.6. Performance comparisons with system overhead.
In this case also, the total query time is measured by varying the probability
of loss over wireless link. But here the agent’s creation time and
marshalling/unmarshalling time is taken into consideration. The size of the
agent’s code is fixed at 8 KB and its time for creation is taken as 0.1 sec. The
marshalling factor value obtained from SerializeTest (using P4 2.0 GHz desktop
with 512 MB RAM running Windows 2000) is 0.00000266 sec/byte or 2.66
ms/KB.
Figure 5.6 represents the results obtained in this case for all the three data
types. It can be seen from the figure that the mobile agent system no longer
provides performance benefits at a lower loss rate (up to 0.2), as was seen
before in Figure 5.3. This denotes considerable overhead of agent’s system
delays. Also the overhead for different data types required to serialize may also
Shah 92
slightly differ. Thus, particularly for this case, it can be said that the mobile agents
are useful only when the probability of loss over wireless link is more than 0.22
for most of the data types.
5.1.4 Effect of Number of Servers Required to Visit
Finally, it is also important to study the performance of mobile agent and
client-server paradigm under the effect of variable number of servers required to
visit in order to complete the task. In all the cases discussed above, the number
of servers was fixed by seeding both the random number generators i.e. one
assigning the probability of having information and the other simulating the
findings of the information. This was done to generate the same output for
comparison purposes. But now it is required to vary the number of servers. So
random number generators are not required. Figure 5.7 shows the results for this
case. It is clear from the graph that the mobile agents are useful only if the
number of servers required visiting for a particular task or query is more than 3
for the given conditions. It should be noted here that the results heavily depend
on the input parameters and change in any of them may considerably change the
mobile agent’s performance.
Shah 93
Figure 5.7. Performance comparisons with variable number of servers.
Shah 94
5.2 Information Retrieval- Scenario 2
In this scenario, consideration has been given to the fact that number of
interactions with the successive server in a list of servers to be visited may
depend on the results obtained from the previous server. For example, consider
a tourist with a mobile device requiring information about the hotels available in
the town to visit. For getting such a list of hotels, he may query a database
registering all the hotels for that town. Now suppose that for each hotel on the
list, he wants to inquire about the rate, for example, with his travel agency’s
database. It is assumed that these two databases are managed on different
machines, by different companies. Thus, the first server provides an interface to
obtain a list of hotels for the given name of the town, while the second server
provides an interface to return the rates for the given hotel name.
This scenario can be analyzed in terms of both client-server and mobile
agent methods. In client-server method, the client’s query to the first server for
getting the list of hotels can be completed using only one RPC call. But once the
list is obtained, the client will have to make one RPC call for each hotel in the list
to the second server. Thus, the total cost of communication can be given as the
sum of one RPC call to server 1 plus n calls to server 2, where n is the number of
hotel records return from query to first server.
In the mobile agent method, the tourist dispatches an agent to the first server
with its request for hotel list. The agent queries the database locally at server 1
and stores the hotel list. Next, it moves to server 2 where it can make local
invocations to find out rates information for all the hotels in the list. Finally, with
Shah 95
all the results stored in it, the agent returns back to the tourist’s mobile device.
Thus this method needs agent to be dispatched only three times; whatever may
be the number of records n retrieved from the first server.
Figure 5.8. Performance comparisons- scenario 2.
Table 5.1. Parameter Values for Scenario-2
Parameters Values
code_size_ 10 KB
err_rate 0.15
m_factor_ 0.0000026
create_delay_ 0.1
req_size 1 KB
Shah 96
As the total time required for the completion of task in client-server method
depends heavily on the number of records retrieved from the server 1, the
simulation is performed by varying this parameter from 1 to 50 records. Each
record is assumed to be of same size of 100 bytes. The parameters used for this
simulation are shown in Table 5.1 and the results obtained are visualized in
Figure 5.8. The figure shows that the mobile agent method is not much efficient
for a small number of records (around 7). But as the number of records increases
from there, the mobile agent provides much more better performance compare to
the client-server method. The initial lower efficiency is mainly contributed to all
the overheads considered in section 5.1. Thus the number of records at which
the cross point is obtained depends heavily on the agent’s size and the agent
system’s overhead.
5.3 Mobile Agents in Middleware for Mobile Device
The importance of middleware in providing the support to mobile devices is
widely accepted now. This section focuses on the study of such a middleware
implemented using mobile agent paradigm and compares it with the more
traditional client-server based middleware communication mechanisms like RMI,
CORBA, etc. The application considered here consists of the adaptive services
provided by the middleware to adapt the contents received by the mobile
devices. These services may include 1) dynamic content adaptation depending
on the type of mobile device used to access the Internet, 2) filtering of some
additional data (e.g. images) that may not be important to the user, 3)
compression of the data to improve the throughput over wireless networks etc.
Shah 97
BaseStation
Gateway MA based
Middleware
InternetServer
MA Home
MobileDevice
Base Station
TraditionalMiddleware
Internet Server
Gateway
Mobile Device
Figure 5.9. Traditional and mobile agent based middleware
Figure 5.9 shows the scenario for both client-server and mobile agent (MA)
based middleware. The client-server based middleware is assumed to be
somewhere in the Internet infrastructure while MA based middleware is located in
the gateway between wired and wireless networks. Each mobile device is
associated with a mobile agent executing in the MA based middleware providing
services to that particular mobile device. Whenever the mobile device moves
from one domain to another, the corresponding mobile agent is also required to
be moved to the gateway machine in the new domain. Thus, the mobile agent
follows the movement of the mobile device. This is simulated by retracting user’s
Shah 98
Table 5.2. Parameter Values for Simulating Middleware
Parameters Values
rep_size_ 50 KB
selectivity (applicableto both C/S and MA)
0.5
m_factor_ 0.0000026
create_delay_ 0.1
req_size 5 KB
Bandwidth (Wired) 1 MB
Bandwidth (Wireless) 1 MB
agent from agent’s home node for the user’s first request to the server. The
parameters used for this simulation are given in Table 5.2.
Figure 5.10 shows the results of the simulation under four different
conditions. The first bar represents a very simple condition in which the mobile
device is located in the home domain only and hence its corresponding mobile-
agent is not required to migrate. The performance for this condition obviously will
be optimum compared to client-server based approach for middleware. This is
because of the extra routing of data packets through the middleware located
elsewhere in the Internet in C/S architecture while MA middleware is located right
near the mobile device on the gateway and hence no extra routing is required.
But the performance of MA middleware degrades whenever the mobile device
moves to another domain. This is because of the time required for mobile agent
Shah 99
migration to remote domain’s gateway and hence the performance now depends
heavily on the size of the agent that is required to be transmitted. Thus the
performance is now a tradeoff between extra routing of data in C/S and size of
the agent to be transmitted in MA paradigm. The third bar in Figure 5.10
represents the MA paradigm for agent size of 5 Kbytes while the fourth bar for
the size of 10 Kbytes. It can be seen here that C/S performs better than MA even
at an agent’s size of only 10 Kbytes.
0
0.5
1
1.5
2
2.5
MA-NoMigration
Client-Server MA-Size 5 K MA-Size 10 K
Tota
l Tim
e R
equi
red
(sec
)
Figure 5.10. Mobile agent / Client-server comparisons
It is important to note here that the performance measure above is only for
the first interaction between the mobile device and the server. As the number of
interactions increases, the MA’s performance should improve. The reason is that
Shah 100
the migration of agent to remote domain is required only once, i.e. for the first
interaction and not for any subsequent interactions. Figure 5.11 shows the
simulation results proving the above argument. Here the total time required is
measured for variable number of interactions with agent’s size of 10 Kbytes and
50 Kbytes. The figure shows that even for agent’s size of 50 Kbytes, the
performance will be better than the C/S paradigm if number of interactions is
more than 3, which will be true for many practical situations.
0
2
4
6
8
10
12
1 2 3 4 5
Number of Interactions
Tim
e R
equi
red
(in s
ec)
MA Size 10 KB MA Size 50 KB Client-Server
Figure 5.11. Effect of number of interactions
Thus, mobile agents may have some performance benefits over C/S
middleware. But this is not the only reason for deploying mobile agents in a
middleware for mobile devices. The effectiveness of mobile agents in middleware
is revealed in their ability to provide user, terminal and resource mobility
(Bellavista 26).
Shah 101
5.4 Overall Analysis of the Results
The overall analysis of the results obtained from the study of various
application scenarios considered here can lead to the following inferences:
• The results obtained in scenario cases described in section 5.1.1 and 5.2
are similar to the earlier results for similar scenarios given in (Jain pg. 6)
and (Ismail pg. 19) respectively. This shows the efficiency of the
simulation model in analyzing the mobile agent applications.
• The performance of the mobile agent technology in wireless applications
heavily depends on various network parameters like available bandwidth
and reliability of the network, as well as agent parameters like agent’s
code and data size, execution environment, number of migrations
required, etc.
• As proposed, mobile agents do have better performance as compared to
client-server techniques in the considered applications, but this is not
always true. Under certain conditions such as reliable network
connections, large size of the agent code, small number of servers to
query, etc., client-server will perform much better than the mobile agents.
The parameter values that may lead to such conditions can be determined
very easily by performing simulation test for the given scenario. This is
shown in sections 5.1 and 5.2 above where such parameter values were
determined using the simulation results.
The above inferences can help mobile agent dynamically choose the method
of interactions based on current network and agent characteristics as follows.
Shah 102
The simulation results can provide the information about the performance likely
to obtained for the current set of parameter values. This information can be
provided to the agent to help it choose dynamically whether to go for migration or
interact remotely using traditional client-server techniques like RPC or RMI. For
example, it is possible to create a stationary service agent that can store the
results obtained from the simulation for various conditions and also can provide
interface to the application agents to query this information. Before going for
migration, the agent can query this service agent and can decide what will be
more efficient, either to dispatch or to make remote invocations.
check_performance( ) Shall_I_Migrate (agent_params) reply ‘yes’ or ‘no’ false use_RMI() true dispatch()
Mobile Agent
Service Agent
reply =‘yes’
Figure 5.12. An example usage of a service agent storing simulation results.
Figure 5.12 shows an example of deploying such a service agent. The
mobile agent queries the service agent using a method like shall_I_Migrate().
Shah 103
The service agent further determines the performance likely to obtained using
simulation results for the given agent and network parameters and replies with
either yes or no. The mobile agent decides whether to dispatch or not with the
help of this reply.
To further illustrate the performance optimization using above concept, lets
consider again the scenario conditions given in section 5.1.2 where the effect of
agent’s code size is studied. According to the results obtained in that section, the
optimum performance can be obtained if the mobile agent migrates only when its
code size is less than 15,000 bytes. Thus if code size is more than 15000 bytes,
the mobile agent may choose to do remote messaging with service agents rather
than migrating to the remote node. Figure 5.13 shows the results obtained from
simulation in this case. The curve represented by “optimum” shows the results
obtained for such a mobile agent using above optimizations.
Figure 5.13. Performance optimization using simulation results
Shah 104
The fact that the mobile agent technology is not always efficient supports the
concept of integration of the mobile agent technology with other software
development tools rather than its sole use for application deployment. The mobile
agent technology should be presented to the application programmer as another
useful tool in the set of tools available for creating robust applications. Thus, an
application developer may choose to use mobile agent technology for some
applications and client-server technology for others.
Shah 105
CHAPTER-6
Conclusion and Future Work
6.1 Conclusion
This thesis addresses the issue of performance analysis of mobile agents in
real-world wireless applications using simulation. We have developed a very
simplified but effective simulation model to study the appropriateness of mobile
agents in any real-world application. This model is implemented by extending the
general-purpose network simulator NS2.
The simulation model thus implemented is used to study the behavior of
mobile agents in some important wireless Internet applications where they are
believed to have better performance. The analysis of the results thus obtained
shows that although the mobile agent provides performance benefits over
traditional client-server techniques, this is not true under all the conditions. Such
conditions have been discussed. The major parameters on which the
performance of mobile agents depends are also presented. Furthermore, it is
proposed that the favorable and unfavorable conditions thus determined could be
provided to the agent to help it dynamically decide whether to employ migration
or to execute client-server interactions in a traditional way. Also, the results
obtained from the simulation studies support the current trend of integrating the
mobile agent technology into the mainstream of industrial software development
rather than treating it as an exotic and specialized offshoot.
Shah 106
6.2 Future Directions
The work done in this thesis has provided a broad base for studies
particularly in deploying the mobile agent technology in real-world applications.
The simulation model developed here may provide a stepping-stone for those
wanting to study the mobile agent technology with availability of only limited
resources. This section tries to point out what can be future extensions to the
contributions made in this thesis.
The mobile agent model implemented here simulates the most basic
behavior of agent technology. Many complex matters have not been considered.
Hence the future work could include the following possible extensions to the
model:
• Only one type of agent’s migration is implemented, in which all the
classes/code associated with an agent has been transmitted. This can be
extended to support other techniques like dynamic class loading on
demand.
• The support for simulating an agent’s code caching may be provided. It
may result in substantial performance benefits when dealing with multiple
agents.
• The model may be extended to support the simulation of services specific
to the mobile devices. These may include 1) provision of docking station,
that facilitates the disconnected operations using mobile agents, and
2) provision of moving proxies, that follows the movement of the mobile
device in the corresponding wired network. The moving proxies can
Shah 107
provide personalized services and QoS adaptation and tailoring to the
mobile device.
• Future work for the mobile agent model could also include the model’s
validation with actual system data if available.
Similarly, the wireless applications studied here are only some of the
fundamental applications well known for deploying the mobile agent technology.
There are many other applications where mobile agent technology seems to be
promising and can be further studied. These include but are not limited to:
• Provision of QoS for wireless multimedia applications where the
mobile agent may be in the form of a user’s proxy moving along with
the mobile user in the corresponding wired network and may provide
dynamic service adaptation and tailoring to the user device depending
on the device and network constraints.
• Provision of personalized services to the portable device that uses the
same proxy based approach to provide information based on the
user’s profile.
• Wireless distributed E-commerce applications; for example, banking
services for portable devices.
Shah 108
REFERENCES
“ACTS”. 1999. AC346: Agent Based Mobile Access to Information Services
(AMASE). Advanced Communication Technologies and Services [accessed 12
April 2003]. Online. Available from
http://www.cordis.lu/infowin/acts/rus/projects/ac346.htm.
“IBM”. 1998. Aglets: Mobile Java Agents. IBM Tokyo Research Lab
[accessed 1 November 2002]. Online. Available from
http://www.trl.ibm.com/aglets.
“Marc Greis”. 1998. Marc Greis’ Tutorial for the Network Simulator NS
[accessed 1 December 2002]. Available from
http://www.isi.edu/nsnam/ns/tutorial/.
“NAM”. 1996. The Network Animator [accessed 15 January 2003]. Available
from http://www.isi.edu/nsnam/nam/.
“NS2”. 1996. The Network Simulator ns-2 Documentation [accessed 1 December
2002]. Available from http://www.isi.edu/nsnam/ns/ns-documentation.html.
“SerializeTest”. 1998. SerializeTest to measure serialization overhead;
[accessed 05 June 2003]. Available from
http://www.sosnoski.com/Java/Timings.html.
Bandyopadhyay, Somprakash, and Krishna Paul. 1999. Evaluating the
performance of mobile agent-based message communication among mobile
hosts in large adhoc wireless network. In Proceedings of the Second ACM
International Workshop on Modeling, Analysis and Simulation of Wireless and
Mobile Systems (August ):69-73.
Shah 109
Baschieri Francesco, Paolo Bellavista, and Antonio Corradi. 2002. Mobile
agents for QoS tailoring, control and adaptation over the Internet: The ubiQoS
video on demand service. IEEE 2002 Symposium on Applications and the
Internet :109-118.
Bellavista, Paolo, and Antonio Corradi. 2002. The ubiquitous provisioning of
Internet services to portable devices. IEEE Pervasive Computing (July/Sept):81-
87.
Breslau, Lee, Deborah Estrin, and Kevin Fall. 2000. Advances in network
simulation. IEEE Computer, vol. 33, no. 5:59-67.
Brewington, Brian, Robert Gray, Katsuhiro Moizumi, David Kotz, George
Cybenko, and Daniel Rus. 1999. Mobile agents in distributed information
retrieval. Chapter 15 in Intelligent Information Agents, edited by M. Klusch.
Berlin: Springer Verlag.
Chess, David, Colin Harrison, and Aaron Kershenbaum. 1995. Mobile
agents: are they a good idea? IBM Research Report, NY.
Chung, Jae, and Mark Claypool. 2000. NS by Example. Worcester
Polytechnic Institute [accessed 1 Feb 2003]. Available from
http://nile.wpi.edu/NS/.
Dikaiakos, Marios, and George Samaras. 2000. Quantitative performance
analysis of mobile agent systems: A hierarchical approach.” Technical Report,
TR-00-2, Dept. of Computer Science, University of Cyprus.
Gray, Robert, David Kotz, and Ronald Peterson. 2001. Mobile agent versus
Client/Server performance: Scalability in an information-retrieval task.” In
Shah 110
Proceedings of the Fifth IEEE International Conference on Mobile Agents,
Atlanta, Georgia, Springer-Verlag (December):229-243.
Gray, Robert, David Kotz, Saurab Nog, Daniel Rus, and George Cybenko.
1996. Mobile agents for mobile computing. In Technical Report PCS-TR96-285,
Dartmouth College.
Hadjiefthymiades, Stathes, Vicky Matthaiou, and Lazaros Merakos. 2002.
Supporting the WWW in wireless communications through mobile agents”.
Mobile Networks and Applications, 7:305-313.
Ismail, L., D. Hagimont, and J. Mossiere. 1999. Evaluation of the mobile
agents technology: Comparison with the Client/Server paradigm. ACM SIGPLAN
Notices, vol. 34, no. 10:306-313.
Jain, Ravi, Farooq Anjum, and Amjad Umar. 2000. A comparison of mobile
agent and Client-Server paradigms for information retrieval tasks in virtual
enterprises. AiWoRC Workshop, Buffalo, New York (April).
Kotz, David, George Cybenko, Robert Gray, Guofei Jiang, and Ronald
Peterson. 2002. Performance analysis of mobile agents for filtering data streams
on wireless networks. Mobile Networks and Applications, 7:163-174.
Kotz, David, Robert Gray, and Daniel Rus. 2002. Future directions for mobile
agent research. IEEE Distributed Systems Online [journal online]; September,
[accessed 1 November 2002]. Available from
http://dsonline.computer.org/0208/f/kot_print.htm.
Shah 111
Kotz, David, Robert Gray, Saurab Nog, Daniel Rus, Sumit Chawla, and
George Cybenko. 1997. Agent Tcl: Targeting the needs of mobile computers.
IEEE Internet Computing, vol. 1, no. 4 (July/August):58-67.
Lange, Danny, and Mitsuru Oshima. 1998. Mobile agents with Java: The
Aglet API. World Wide Web, vol. 1, no. 3:n.pag.
---. 1999. Seven good reasons for mobile agents. In Communications of the
ACM, vol.42, no.3: 88-89.
Law, Averill, and W. David Kelton. 2000. Simulation modeling and analysis.
3rd ed. New York: McGraw-Hill.
Mahmoud, Q. 2001. MobiAgent: A mobile agent-based approach to wireless
information systems. Proceedings of the 3rd International Bi-Conference
Workshop on Agent Oriented Information Systems (AOIS-2001), Montreal.
Milojicic, D.S., D. Chauhan, and W. laForge. 1998. Mobile Objects and
Agents (MOA), design, implementation and lessons learned. In The Fourth
USENIX Conference on Object-Oriented Technologies (COOTS) (April): 179-
194.
Spalink, Tammo, John Hartman, and Garth Gibson. 1998. The effect of
mobile code on file service. Technical Report TR98-12, Department of Computer
Science, University of Arizona (November).
Srasser, Markus, and Markus Schwehm. 2000. A performance model for
mobile agent systems. In Proceedings of the Autonomous Agents 2000
Workshop on Agents in Industry, Barcelona, Spain (2000).
Shah 112
Sun Microsystems. 2002. Mobile Information Device Profile (MIDP). Sun
Microsystems, Inc [accessed 1 June 2003]. Online. Available from
http://java.sun.com/products/midp.
Walsh, Tom, Noemi Paciorek, and David Wong. 1998. Security and reliability
in Concordia. In Proceedings of 31st Hawaii International Conference on Systems
Sciences, VII:44-53.
White, James. 1996. Telescript technology: Mobile agents. In Software
agents, edited by J.M.Bradshaw. Cambridge, MA: The AAAI Press/The MIT
Press.
Shah 113
APPENDIX: User’s Guide to Mobile Agent Model
A.1 Model Parameters Accessible Through OTcl
The parameters of the mobile agent object that are accessible by the user
are given in Table A.1. The default values of these parameters are defined in
~ns/tcl/lib/ns-default.tcl.
Table A.1. OTcl Parameters for Mobile Agent Object
Parameter Comments
Id_ Agent’s Id that is unique among all the agents currently
executing in all the contexts. It is assigned by the model
whenever a new agent is created and hence should not
be set.
code_size_ The size (in bytes) of the agent code that is required to
be transmitted.
data_size_ The size (in bytes) of agent’s data that is required to
carry away while migrating.
status_size_ The size (in bytes) of the agent’s current execution
stack. This parameter will be zero for agent systems
deploying weak migration.
Shah 114
Table A.1. OTcl Parameters for Mobile Agent Object, continued
Parameter Comments
rep_size_ The actual size (in bytes) of the results expected
from the interaction without considering the agent’s
remote processing/filtering ability,
selectivity_ The factor by which the mobile agent reduces the
size of the results (rep_size_) by remote processing
or filtering.
m_factor_ The marshalling or serialization overhead (in
sec/byte). This overhead can be obtained from
experiments by measuring the time required to
serialize and de-serialize a certain amount of data.
process_delay_ The processing time of the agent at a particular
context (in sec). This can be also set as a factor
proportional to the agent code size. Please refer to
the C++ class MAgent for details.
create_delay_ The time (in sec) required for creating a single agent.
Please note here that no code caching is considered
in this model. Hence the creation time will be the
same for all the agents whatever number of them is
created. This parameter is defined in OTcl only.
homenode_ The home node for the mobile agent. This is set at
the creation of the agent and is also defined only in
OTcl.
Shah 115
A.2 Procedures Available to User Through OTcl
These procedures consists of all the instance procedures implemented in an
OTcl class as well as corresponding C++ shadow methods defined through
command() method of C++ class..
The following is the list of C++ shadow methods available to the user through
OTcl for the MAgent class. Shadow methods are shown in the form of OTcl
instance procedures for realizing how they can be used as such procedures.
Please see the simulation script given in section A.3 for their example usage.
• MAgent instproc run arg1 :# entry point for the mobile agent that user
# is required to define to implement the mobile agent task. Please see
# the simulation script given in A.3 for example.
• MAgent instproc context ;# returns the current context of execution
• MAgent instproc node ;# returns the current node of execution
• MAgent instproc is_active ;# checks the current state of the agent
• MAgent instproc dispose ;# deletes the agent object and detaches
# itself from the list of agents in the current context
• MAgent instproc dispatch
;# dispatch to the context to which the current context is connected to.
• MAgent instproc dispatch arg1 ;# dispatch to the context given by arg1
• MAgent instproc deactivate arg1 ;# deactivation for time given by arg1
• MAgent instproc clone ;# make an exact copy of the current agent
• MAgent instproc removeMobilityListener
• MAgent instproc removeCloneListener
Shah 116
• MAgent instproc removePersistencyListener
# removes the corresponding listeners
On the other side the following three methods are defined only in OTcl part of
class MAgent.
• MAgent instproc addMobilityListener
• MAgent instproc addCloneListener
• MAgent instproc addPersistencyListener
# adds the corresponding listeners
The following are the procedures available to the user for overriding in order
to define certain tasks to be done at certain events. However, in order to use
these event listeners, the corresponding listener must be added to an agent
through the procedures mentioned above like ‘addMobilityListener’ etc.
# User can override any of the following instance procedures in order to define
# the task to be executed at the corresponding event.
# Class MobilityAdapter – For events related to mobility of the agent.
MobilityAdapter instproc onArrival { }
# on arrival of an agent to a new node
MobilityAdapter instproc onReverting { }
# on reverting from other node to the current node.
MobilityAdapter instproc onDispatching { }
# to do the finish work before dispatching to a new node
Shah 117
# Class CloneAdapter – For events related to agent’s cloning.
CloneAdapter instproc onClone {} ;# executed on the newly created clone
CloneAdapter instproc onCloning {} ;# executed before cloning of an agent
CloneAdapter instproc onCloned {}
;# executed on an agent that has undergone cloning.
# Class PersistencyAdapter – For evemts related to activation and deactivation
#of the agent
PersistencyAdapter instproc onActivation { }
;# invoked after agent is activated.
PersistencyAdapter instproc onDeactivating { }
;# invoked before agent is deactivated.
The instance procedures available to the user for the class Context provides
mainly with creation and maintenance of the agents and are given next. C++
shadow methods are as follows:
• Context instproc start ;# starts the context after which it can create and
# receive agents. Agents will not be received if the context is not started.
• Context instproc shutdown ;# disable the context so that it does not
provide support to any agents.
• Context instproc node ;# returns the node on which context is deployed
• Context instproc getAgent arg1
# returns an OTcl agent object with Id given by arg1.
Shah 118
• Context instproc retractAgent arg1 ;# retract (pull) the agent with unique
Id given by arg1 to the current context.
• Context instproc startAgent arg1 arg2
# not for direct used., but is used by OTcl instance procedure
# create-agent. Here arg1 represents the agent’s name and optional
# arg2 represent a string that can be used to initialize an agent.
The following two are the pure OTcl instance procedures that are defined
only in OTcl class Context.
• Context instproc create-agent arg1 arg2
# creates, initializes and executes an agent with name given by arg1.
# The user is required to create an agent instance and invoke this
# procedure as shown in example script (section A.3).
• Context instproc connect-to arg1
# connects current context to the context given by arg1. This includes
# connection at the application level as well as connection between
# transport layer agents. This procedure should be invoked before calling
# for agent’s dispatch.
Shah 119
A.3 An Example Script
# Script simulating the behavior of mobile agents in wired-cum wireless # scenario as described in section 5.1.1 under ideal conditions for # mobile agents. The scenario consists of 8 servers (wired nodes) and a # mobile node acting as a client. The mobile node is connected to the # wired network through a base station node. All the servers and the # client node have a context or place for creating and executing # agents. The context of mobile node creates and starts a mobile agent # in order to accomplish an information retrieval task. For this task # agent is required to migrate to different servers in turn and to look # for the requested information. Each server is assigned a certain # probability of having the information required. If the agent finds # the information at any server, it returns back to the original mobile # node and does not required to check any more servers. The performance # of mobile-agent in terms of total time required to finish the task is # measure for the given probability of loss over wireless channel. ####################################################################### #################### Code for Scenario Setup ########################## ####################################################################### #====================================================================== # Define options # #====================================================================== set opt(chan) Channel/WirelessChannel ;# channel type set opt(prop) Propagation/TwoRayGround ;# radio-propagation model set opt(netif) Phy/WirelessPhy ;# network interface type set opt(mac) Mac/802_11 ;# MAC type set opt(ifq) Queue/DropTail/PriQueue ;# interface queue type set opt(ll) LL ;# link layer type set opt(ant) Antenna/OmniAntenna ;# antenna model set opt(ifqlen) 50 ;# max packet in ifq set opt(nn) 1 ;# number of mobilenodes set opt(adhocRouting) DSDV ;# routing protocol set opt(x) 670 ;# x coordinate of topology set opt(y) 670 ;# y coordinate of topology set opt(seed) 0.0 ;# seed for random number gen. set opt(stop) 30 ;# time to stop simulation set opt(app_start) 10 ;# time to start the agent application set opt(err_rate) [lindex $argv 0]
# rate of packet loss getting from command line set latency 0 # Measuring execution time requirement set num_wired_nodes 8 # total # of servers set num_bs_nodes 1 # number of base-station nodes # Setting bandwidth and delay for the MAC layer of wireless network Mac/802_11 set dataRate_ 500Kb Mac/802_11 set basicRate_ 500Kb
Shah 120
LL set delay_ 10ms # ======================================================================= # check for boundary parameters and random seed if { $opt(x) == 0 || $opt(y) == 0 } { puts "No X-Y boundary values given for wireless topology\n" } if {$opt(seed) > 0} { puts "Seeding Random number generator with $opt(seed)\n" ns-random $opt(seed) } proc DEBUG text { # Ouput debug text puts "DEBUG: $text" } # create simulator instance set ns_ [new Simulator] # create trace files set tracefd [open mobile-agent.tr w] set namtrace [open mobile-agent.nam w] # use new trace from CMU $ns_ use-newtrace $ns_ trace-all $tracefd $ns_ namtrace-all $namtrace # set up for hierarchical routing $ns_ node-config -addressType hierarchical AddrParams set domain_num_ 2 ;# number of domains lappend cluster_num 10 1 ;# number of clusters in each domain AddrParams set cluster_num_ $cluster_num lappend eilastlevel 1 1 1 1 1 1 1 1 1 1 2 ;# number of nodes in each cluster AddrParams set nodes_num_ $eilastlevel ;# of each domain # Create topography object set topo [new Topography] # define topology $topo load_flatgrid $opt(x) $opt(y) # create God create-god [expr $opt(nn) + $num_bs_nodes] #create wired nodes set temp {0.0.0 0.1.0 0.2.0 0.3.0 0.4.0 0.5.0 0.6.0 0.7.0 0.8.0 0.9.0} ;# hierarchical addresses for wired domain for {set i 0} {$i < $num_wired_nodes} {incr i} { set W($i) [$ns_ node [lindex $temp $i]] }
Shah 121
# new way of configuring wireless channel set chan [new $opt(chan)] # configure for base-station node $ns_ node-config -adhocRouting $opt(adhocRouting) \ -llType $opt(ll) \ -macType $opt(mac) \ -ifqType $opt(ifq) \ -ifqLen $opt(ifqlen) \ -antType $opt(ant) \ -propType $opt(prop) \ -phyType $opt(netif) \ -channel $chan \ -topoInstance $topo \ -wiredRouting ON \ -agentTrace ON \ -routerTrace OFF \ -macTrace OFF $ns_ node-config -OutgoingErrProc UniformErr # introdue the error-model to simulate packet loss in the outgoing # packets of the wireless channel proc UniformErr { } { global opt set err [new ErrorModel] $err unit packet set rng [new RNG] $rng seed 1 $err ranvar [new RandomVariable/Uniform] $err set rate_ $opt(err_rate) return $err } #create base-station node set temp {1.0.0 1.0.1 1.0.2 1.0.3} ;# hier address to be used for wireless ;# domain set BS(0) [$ns_ node [lindex $temp 0]] $BS(0) random-motion 0 ;# disable random motion #provide some co-ord (fixed) to base station node $BS(0) set X_ 1.0 $BS(0) set Y_ 2.0 $BS(0) set Z_ 0.0 # create mobilenodes in the same domain as BS(0) # note the position and movement of mobilenodes is as defined # in $opt(sc) #configure for mobilenodes $ns_ node-config -wiredRouting OFF for {set j 0} {$j < $opt(nn)} {incr j} { set node($j) [ $ns_ node [lindex $temp \ [expr $j+1]] ]
Shah 122
$node($j) base-station [AddrParams addr2id \ [$BS(0) node-addr]] } #create links between wired and BS nodes $ns_ duplex-link $W(0) $BS(0) 5Mb 2ms DropTail $ns_ duplex-link-op $BS(0) $W(0) orient right #create links between different wired nodes proc makelinks { bw delay pairs } { global ns_ W BS foreach p $pairs { set src $W([lindex $p 0]) set dst $W([lindex $p 1]) $ns_ duplex-link $src $dst $bw $delay DropTail $ns_ duplex-link-op $src $dst orient [lindex $p 2] } } makelinks 1Mb 10ms { { 0 1 left-up } { 0 2 up } { 0 3 right-up } { 0 4 right } { 0 5 right-down } { 0 6 down } { 0 7 left-down } } ###################################################################### ############# Code Related to Mobile Agent Model ##################### ###################################################################### # Open file to write output for the current execution set f0 [open mobile-agent a] # Source the OTcl files for Mobile Agent Model to use it in current # script. This is required for using the model. source ../MAgent.tcl source ../Context.tcl # Entry point method for the mobile-agent. # This method defines the task to be performed by the agent. MAgent instproc run {c} { $self instvar context_ homenode_ job_done_ global ns_ num_wired_nodes count_ latency opt context set node_ [$self node] set context_ $c if {$job_done_ == 0 } { ;# if job is not finished yet
#if original node is visited then the agent might have just #started or returned back without finding information
if { $node_ == $homenode_ } { if { $count_ == 0 } { DEBUG "I am at original host at time
[$ns_ now]. start working now" set dstcontext $context([expr $count_+1]) $context_ connect-to $dstcontext
Shah 123
$self dispatch } else {
DEBUG " No Information found at any server.. Agent Disposing "
record $self dispose } } else {
#agent is at remote context so look for the information required. # if it is not found dispatch to next server, otherwise dispatch # back to originating node
set job_done_ [is_info_found $count_] set count_ [expr $count_ +1] if { $job_done_ == 0 && $count_ < $num_wired_nodes} { set dstcontext $context([expr $count_+1]) } else { set dstcontext $context(0) } DEBUG "Preparing to go next destination $dstcontext" $context_ connect-to $dstcontext $self dispatch } } else { # job is done and agent returned back to home. Record the results # and dispose the agent. DEBUG "Aglet Returned Home: JOB IS DONE." DEBUG "Information found on Server $count_" DEBUG " Aglet now Disposing" record $self dispose return } } # defining the mobility adapter class to define its event handlers # Note that this is only for example usage and is not required for # current scenario MobilityAdapter instproc init args { eval $self next $args $self instvar context_ } MobilityAdapter instproc onArrival args { puts "onArrival: method is called " } MobilityAdapter instproc onDispatching args { DEBUG "method onDipatching is called " } # Event handler corresponding to agent’s creation. # Does little initialization for the agent.
Shah 124
MAgent instproc onCreation args { $self instvar job_done_ homenode_ set homenode_ [$self node] set job_done_ 0 } # Create the transport layer agents to be associate with the context # for agent transmission. # Tcp agents for mobile node set recv_tcp(0) [new Agent/TCP/FullTcp] $ns_ attach-agent $node(0) $recv_tcp(0) set send_tcp(0) [new Agent/TCP/FullTcp] $ns_ attach-agent $node(0) $send_tcp(0) set context(0) [new Application/TcpApp/Context $recv_tcp(0) $send_tcp(0) $node(0)] # Tcp agents for wired nodes (servers) for {set i 0} {$i < $num_wired_nodes} {incr i} { set recv_tcp([expr $i+1]) [new Agent/TCP/FullTcp] $ns_ attach-agent $W($i) $recv_tcp([expr $i+1]) set send_tcp([expr $i+1]) [new Agent/TCP/FullTcp] $ns_ attach-agent $W($i) $send_tcp([expr $i+1]) set context([expr $i+1]) [new Application/TcpApp/Context $recv_tcp([expr $i+1]) $send_tcp([expr $i+1]) $W($i)] } set count_ 0 ;# identifier of current server visited ######### Schedule activities ############ # Create and send Agents $ns_ at $opt(app_start) {
# Initialize the contexts
$context(0) start for {set i 1} {$i < $num_wired_nodes} {incr i} { $context($i) start } # creating mobile-agent instance and setting some parameters set agent [new MAgent]
$agent set code_size_ 0 ;# representing ideal conditions # with no code size overhead
$agent set data_size_ 5000 # Adding the listener for mobility related events $agent addMobilityListener # starting the agent from context 0 sitting on the mobile node. $context(0) create-agent $agent } ### Record the output i.e. total time required for the task proc record { } {
Shah 125
global ns_ opt f0 set latency [expr [$ns_ now] - $opt(app_start)] puts $f0 "$opt(err_rate) $latency" } # Generation of probability of having information at different servers # Probability is uniformly distributed between 0 and 1 set rng [new RNG] $rng seed 12345 set u [new RandomVariable/Uniform] $u use-rng $rng $u set min_ 0 $u set max_ 1 for {set i 0} {$i<$num_wired_nodes} {incr i} { set prob($i) [$u value] } # Simulation the findings of the information at a particular server # based on its probability. proc is_info_found {count_} { global prob set rng [new RNG] $rng seed 67890 set v [new RandomVariable/Uniform] $v use-rng $rng $v set min_ 0 $v set max_ 1 set val [$v value] if { $val < $prob($count_) } { return 1 } else { return 0 } } # Tell all nodes when the simulation ends for {set i } {$i < $opt(nn) } {incr i} { $ns_ at $opt(stop).0 "$node($i) reset"; } $ns_ at $opt(stop).0 "$BS(0) reset"; $ns_ at $opt(stop).0002 "puts \"NS EXITING...\" ; $ns_ halt" $ns_ at $opt(stop).0001 "stop" # close all the trace files while stopping the simulation proc stop {} { global ns_ tracefd namtrace f0 $ns_ flush-trace close $tracefd close $namtrace close $f0 } puts "Starting Simulation..." $ns_ run ;# finally run the simulation. ############################# End of Script ########################## #######################################################################
