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
138
Embed
PERFORMANCE ANALYSIS OF MOBILE AGENTS IN WIRELESS INTERNET
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
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.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
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 ########################## #######################################################################