Thesis Final

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 ClientServer paradigm 7 2.1.5 What Mobile Agents can do for us? 9 2.2 Survey of Mobile Agent Systems 2.2.1 Java-based systems 2.2.2 Multiple Language Systems 2.2.3 Other Systems 2.2.4 Brief comparison of Mobile Agent Systems

11 11 12 13 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 4.1 Introduction to Network Simulator (NS2) 4.1.1 Software Architecture 4.1.2 C++ - OTcl Linkage 4.1.3 Major Components 4.1.4 Further directions

30 30 30 31 33 34

4.2 Why NS2?

34

4.3 Design and Implementation of Mobile Agent Model

35

4.3.1 Assumptions 4.3.2 Deciding the Inheritance Structure of the Model 4.3.3 Transferring Application-level data in NS 4.3.4 Design Overview 4.3.5 C++ and OTcl linkage for the Model 4.3.6 Mobile Agent Model Parameters 4.3.5 Mobile Agent Methods 4.3.6 Mobile Agent’s Event Listeners 4.3.7 Purpose and Functioning of MAgletInst class 4.3.8 Methods Implemented in class Context 4.3.9 Modeling of Agent’s Timer 4.3.10 OTcl Interface for the mobile agent model

35 36 38 40 43 49 51 54 55 56 58 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 5.1 Information Retrieval- Scenario 1 5.1.1 Ideal Conditions for Mobile agent Systems with No Overhead 5.1.2 Effect of the Mobile Agent’s Size Overhead 5.1.3 Effect of Creation and Marshalling/Serialization Overhead 5.1.4 Effect of Number of Servers Required to Visit

78 78 86 88 90 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.

communication.

That

is, ongoing interaction requires ongoing

Shah 8

Remote Interactions

Server App.

Client App.

Remote Server

User

Figure 2.1. Communications using client-server paradigm.

Local Interactions Mobile Agent

User

Mobile Agent

Server App.

Remote Server

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 microbenchmarks 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 datafiltering 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 clientserver 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 Application/ Traffic/ Exponential

Simulated applications

Application/FTP

API

API

Agent/UDP

Agent/TCP/FullTcp

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)

Application Wrapper (TcpApp) send(bytes)

recv(bytes) Agent (FullTcp)

packets

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.

TclObject

Process TclObject Application MAgent Application/TcpApp

Application/TcpApp/Context

Figure 4.5. Class hierarchies for the model.

TimerHandler

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

TcpApp

AppData

extends Context

extends contains

MobileAgentData

MobilityListner

contains contains MAgent

contains

CloneListner

contains extends

PersistencyListner

MAgentInst

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

TclObject

C++ class hierarchy

otcl class hierarchy

Application

TclObject

Process

Application/TcpApp

Application

Context

Application/TcpApp/Context

-o256

context_

Application/TcpApp/Context otcl Shadow Object

Context C++ Object

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 bidirectional 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

Unique ID or name given to a mobile agent. This ID is Id_

unique among all the mobile agent objects currently existing in the simulation environment.

code_size_

Represents the size of the code and data of a mobile

data_size_

agent respectively (in bytes). Represents the size of the status stack of the agent during migration. This will be required only for strong

status_size

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. Reference to a hash table use to store references of all the

agent_list_ 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 ()

Adds respective listeners that will listen to

void addPersistencyListener()

corresponding activities of the agent

void addCloneListener() void removeMobilityListener()

Removes the corresponding listeners that

void removePersistencyListener()

are no more required.

void removeCloneListener() void startCreatedAgent (const

Starts the agent after the corresponding

char*, Context*, int )

events like creation, arrival to a new context

void startArrivedAgent (Context* )

and

retraction

from

a

remote

context

respectively. void startRetractedAgent (Context* )

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* Moves the agent represented by key “id” context, int size)

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 subdirectory 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

ns-allinone

Tcl , Tk ,Nam and other packages

tcl

ns-2

Makefile.in

Otcl

tcp

apps

Tclcl

other C++ code

mobile agents (C++)

ex

test

lib

mcast

other OTcl code

mobile agents (OTcl)

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 User

2 OTcl Interpreter

11

4

10 3 Mobile Agent (agent_)

5

6

9

7 Context 1 (context1_)

Context 2 (context2_)

Other ns modules

8

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).

Input Parameters

Same

Mathematical Model

Output Data

Input Parameters

Simulation Model

Compare

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

80,976 bytes/sec

Throughput

or 647.81 Kbps

Latency

20 ms

Throughput (Bytes/sec)

Shah 75

88000 86000 84000 82000 80000 78000 76000 74000 72000 70000 68000 66000 0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Selectivity of the Agent

Figure 4.11. Variation of throughput with agent’s selectivity

0.7

Time Required for the Interaction

0.6

0.5

0.4

0.3

0.2

0.1

0 0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Selectivity of the Agent 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 meandifference 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

Simulation Model

Mathematical Model

Difference

Output (Xi)

Output (Yi)

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)

= |(Zmean/Ymean)* 100|

4.406820

Selectivity

Percentage Difference

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-cumwireless 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 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} wireless

;# hier address to be used for

;# domain set BS(0) [$ns_ node [lindex $temp 0]] $BS(0) random-motion 0 ;# disable random motion #provide some $BS(0) set X_ $BS(0) set Y_ $BS(0) set Z_

co-ord (fixed) to base station node 1.0 2.0 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