Mobile Agent Thesis

PERFORMANCE ANALYSIS OF MOBILE AGENTS IN WIRELESS INTERNET APPLICATIONS USING SIMULATION

A Thesis Presented to The Faculty of the College of Graduate Studies Lamar University

In Partial Fulfillment of the Requirements for the Degree Master of Science

by Kunal Shah August 2003

PERFORMANCE ANALYSIS OF MOBILE AGENTS IN WIRELESS INTERNET APPLICATIONS USING SIMULATION KUNAL SHAH

Approved:

________________________________ Lawrence Osborne Supervising Professor

________________________________ Hikyoo Koh Committee Member

________________________________ Dehu Qi Committee Member

____________________________ Lawrence Osborne Chair, Department of Computer Science

_____________________________ Jack R. Hopper Dean, College of Engineering

______________________________ Jerry W. Bradley Associate Vice President for Research and Dean of Graduate Studies

© 2003 by Kunal Shah

No part of this work can be reproduced without permission except as indicated by the “Fair Use” clause of the copyright law. Passages, images, or ideas taken from this work must be properly credited in any written or published materials.

ABSTRACT Performance Analysis Of Mobile Agents In Wireless Internet Applications Using Simulation

By: Kunal Shah, M.S. Lamar University

In today’s information society, users are overwhelmed by the information with which they are confronted on a daily basis. However, for subscribers of mobile wireless services, this may present a problem. Wireless devices are connected via wireless networks that suffer from low bandwidth and also have a greater tendency for network errors. Additionally, wireless connections can be lost or degraded by mobility. The mobile agent technology offers very promising solution to this problem. Mobile agents can migrate from host to host in a network of computers. Their mobility allows them to move across an unreliable link to reside on a wired host, next to or closer to the resources that they need to use. Furthermore, client-specific data transformations can be moved across the wireless link and run on a wired gateway server, reducing bandwidth demands. There have been extensive researches going on in the development of the mobile agent systems. But there are not many efforts in the study of their performance in real world applications and very few in wireless networks. As a result, the spread of mobile agent technology in the real world applications cannot be seen yet. The main obstacles faced by the researchers are the

complexity of evaluating distributed applications in heterogeneous networks and expenses of building test beds for their experiments. A computer simulator can overcome these obstacles. A simulator is able to provide users with practical feedback when designing real world applications. Thus, the main objectives of this thesis are to implement a tool to simulate the behavior of mobile agents and to utilize this tool for the performance analysis of mobile agents in wireless services. The implementation consists of extending the existing network simulator NS2 to support mobile agents’ simulation. It has been tried to use IBM’s Aglets API whenever possible to ease both the understanding of the code and its usage for implementing agent based simulated applications. NS2, along with the extension made, then has been used to study the performance of mobile agents in some of their promising applications in Wireless Internet Services viz. information retrieval. Their performance is compared to that of the client/server model. The results show that significant performance improvements can be obtained using mobile agents but only in certain situations. While in other situations client/server model has better performance. Such situations has been determined and can be very helpful in deciding dynamically which one of the two should be used for optimum performance.

ACKNOWLEDGEMENTS I am indebted to my advisor Dr. Lawrence Osborne for all the motivation, support and direction he has provided. He has been an invaluable source of knowledge and ideas and I appreciate his flexibility in allowing me to pursue my own research ideas. I would like to thank Dr. Hikyoo Koh for his valuable guidance and his role on my committee. I am also thankful to Dr. Dehu Qi for his helpful suggestions as a member of my committee. I am also grateful to Prof. Paolo Bellavista at DEIS-LIA - Università degli Studi di Bologna, Italy for his guidelines and support for this research. I would also like to thank Ms. Donna Blaisdell, Departmental Secretary and Mr. Frank Sun, Senior System Administrator for always being supportive to me. I would also like to take this opportunity to thank Mr. Gary Laird, Director Developmental Studies for sparing his valuable time in proofreading this thesis. I would like to express my gratitude to my parents for their incredible support. They have done whatever they could do to make sure that I could get the best education possible and have always encouraged me to strive for the best. Finally a special thanks to my wife without whose moral support and encouragement, it would have been impossible to finish this work.

iii

TABLE OF CONTENTS LIST OF TABLES LIST OF FIGURES CHAPTER-1 Introduction 1.1 Motivation 1.2 Performance Analysis using Simulation 1.3 Organization of the Thesis CHAPTER-2 Background and Literature Survey 2.1 Overview of Mobile Agents vii viii 1 1 2 3 3 5 5 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 2.3 Competing Technologies and Comparisons 2.4 Related Works And Their Contribution CHAPTER-3 Mobile Agents in Wireless Internet Services 3.1 How Mobile Agents fit in Wireless Networks? 3.2 Supports for adapting Mobile Agents in Wireless Services 3.3 Potential Wireless Applications of Mobile Agents 11 11 12 13 13 15 18 21 21 21 23 27

iv

CHAPTER-4 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 4.2 Why NS2? 4.3 Design and Implementation of Mobile Agent Model 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 4.4 Adding mobile agent model to NS package 4.5 Model Interactions 4.6 Problems encountered and their work-around 4.7 Validating the Mobile Agent Model CHAPTER-5 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 5.2 Information Retrieval- Scenario 2 5.3 Mobile Agents in Middleware for Mobile Device

30 30 30 30 31 33 34 34 35 35 36 38 40 43 49 51 54 55 56 58 61 62 64 68 71 78 78 78 86 88 90 92 94 96

v

5.4 Overall Analysis of the Results CHAPTER-6 Conclusion and Future Work 6.1 Conclusion 6.2 Future Directions REFERENCES APPENDIX: User’s Guide to Mobile Agent Model A.1 Model Parameters Accessible Through OTcl A.2 Procedures Available to User Through OTcl A.3 An Example Script

101 105 105 105 106 108 113 113 115 119

vi

LIST OF TABLES Table 4.1. Parameters of a Mobile Agent ........................................................... 49 Table 4.2. Parameters of a Context.................................................................... 51 Table 4.3. Methods Implemented in MAgent Class ............................................ 52 Table 4.4. Methods iplemented in Context class ................................................ 57 Table 4.5. Sequence of Interactions ................................................................... 67 Table 4.6 Parameter Values used for Validation ................................................ 74 Table 4.7. Output from Models and their Differences ......................................... 77 Table 5.1. Parameter Values for Scenario-2 ..................................................... 95 Table 5.2. Parameter Values for Simulating Middleware................................... 98 Table A.1. OTcl Parameters for Mobile Agent Object....................................... 113

vii

LIST OF FIGURES Figure 2.1. Communications using client-server paradigm................................... 8 Figure 2.2. Communications using mobile agent paradigm.................................. 8 Figure 4.1. C++ -- OTcl linkage. ......................................................................... 31 Figure 4.2. Major components in NS. ................................................................. 33 Figure 4.3. Application layer in NS. .................................................................... 37 Figure 4.4. Transferring user level data in NS. ................................................... 39 Figure 4.5. Class hierarchies for the model. ....................................................... 41 Figure 4.6. Class relationship of the model. ....................................................... 43 Figure 4.7. C++ and OTcl linkage for the model. ................................................ 44 Figure 4.8. Adding mobile agent model to NS. ................................................... 63 Figure 4.9. Model interactions for an example scenario. .................................... 66 Figure 4.10 Validation of the Mobile agent Model............................................... 73 Figure 4.11. Variation of throughput with agent’s selectivity............................... 75 Figure 4.12. Comparison of mathematical and simulation model. ...................... 75 Figure 5.1. Information retrieval - scenario 1. ..................................................... 79 Figure 5.2. Visualization of scenario 1 using NAM. ............................................ 80 Figure 5.3. Performance comparison- ideal conditions....................................... 87 Figure 5.4. Performance ratio mobile-agent/client-server................................... 87 Figure 5.5. Performance comparisons with variable agent code size................. 89 Figure 5.6. Performance comparisons with system overhead. ........................... 91 Figure 5.7. Performance comparisons with variable number of servers. ............ 93 Figure 5.8. Performance comparisons- scenario 2. ............................................ 95

viii

Figure 5.9. Traditional and mobile agent based middleware .............................. 97 Figure 5.10. Mobile agent / Client-server comparisons ...................................... 99 Figure 5.11. Effect of number of interactions.................................................... 100 Figure 5.12. An example usage of a service agent storing simulation results. . 102 Figure 5.13. Performance optimization using simulation results....................... 103

ix

x

Shah 1

CHAPTER-1 Introduction In the recent years, growth of the Internet has exploded with the appearance of World-Wide Web. Today, network and computer technology along with the services and information available on the Internet are growing so fast that we will soon reach to the point where hundred of millions of people will have fast, pervasive access to a substantial amount of information from anywhere and anytime. The advancement experienced in the area of wireless personal communications is enormous. The European cellular system GSM has received an impressive acceptance and spread rapidly over the world. Also office

environments and industrial installations have benefited from the introduction of various standards like IEEE 802.11. The growth of wireless telecommunications coupled with proliferation of portable computing equipment (laptops, personal digital assistants) has stimulated the interest for the anywhere-anytime computing, also known as “nomadic computing”. Nomadic computing aims to provide users with access to popular desktop applications, applications especially suited for mobile users, and basic communication services. Observing the growing demands of mobile users, it can be predicted that the next generation wireless networks will be burdened with bandwidth-intensive traffic generated by applications such as web browsing, traveler information systems, video and games. However, the available resources (e.g. bandwidth) for supporting such applications are extremely limited. Additionally wireless

Shah 2 networks have a greater tendency for network errors and also wireless connections can be lost or degraded by mobility. The mobile agent technology offers very promising solution to these problems. Mobile agents can migrate from host to host in a network of computers. Their mobility allows them to move across an unreliable link to reside on a wired host, next to or closer to the resources that they need to use. Furthermore, client-specific data transformations can be moved across the wireless link and run on a wired gateway server, reducing bandwidth demands. 1.1 Motivation For the past several years, researchers and developers have put substantial efforts in the development of the basic technology for mobile agents. This has resulted into several robust and efficient but monolithic mobile agent systems. Researchers have now pointed out (Kotz, Gray, and Rus 2002) that this monolithic approach to mobile agent systems is harming the spread and acceptance of mobile code in general. Wireless application developers are hesitant to create applications that require use of a new, large, monolithic system that are not tailored to their specific needs and thus resulting in significant overheads. Hence the performance benefits offered by the mobile agents, as discussed above, are not clear yet. There are only few studies done on

quantitative performance of mobile agents. As a result, there has been a little motivation for developers to use mobile agents.

Shah 3 Thus, in order to motivate the use of mobile agents it is required to show those in other fields including application development, that mobile agents are valuable and for that, more quantitative study on mobility’s value is required. 1.2 Performance Analysis using Simulation Although the requirement of more performance studies is understood now, there are many hindrances in the way of accomplishment of these studies. The most prominent is the complexity of evaluating the performance of mobile agent applications in heterogeneous networks, typical of wireless applications. The cost of building test-bed or actual systems for performance analysis is sometimes not effective or even not feasible. The intensity of the problem increases, as more and more real world applications deploying mobile agents are proposed and each need different configuration parameters for performance studies. For these reasons, it is necessary to build a simulation model of the general mobile agent behavior and study it as a surrogate for an actual system. In this thesis, we have tried to build a model for simulating the general behavior of mobile agents by extending the existing network simulator NS2. Using this model, the performance of the mobile agents is studied and compared with more traditional client-server approach. 1.3 Organization of the Thesis The rest of the thesis is organized as follows. Chapter 2 gives background on mobile agents including an overview of major mobile agent systems and other competing technologies. It also discusses the research work relevant to this

Shah 4 thesis. Chapter 3 further details the appropriateness of mobile agents in wireless services and lists the support provided by recent researches in adapting them in wireless networks. Chapter 4 details the extension provided to NS2 in order to support mobile agents and the actual implementation of mobile agent model. Chapter 5 discusses the performance of some of the potential mobile agent applications in wireless services with both mobile agent and client-server paradigms using NS2. Chapter 6 concludes this thesis with a note on future research directions.

Shah 5

CHAPTER-2 Background and Literature Survey 2.1 Overview of Mobile Agents 2.1.1 A Software Agent As per the IBM’s definition (Lange and Oshima 1998), an agent is a software object that • • • • is situated within an execution environment acts on behalf of others in an autonomous fashion. performs its actions in some level of pro-activity and reactivity exhibits some levels of the key attributes of learning, cooperation, and mobility. 2.1.2 Mobile vs. Stationary Agents Mobility is an orthogonal property of agents. That is, all agents are not necessarily required to be mobile. An agent can remain stationary and

communicate with the surroundings by conventional means like remote procedure calls (RPC) and remote object invocation (RMI) etc. The agents that do not or cannot move are called stationary agents. On the other side, a mobile agent is not bound to the system where it begins execution. The mobile agent is free to travel among the hosts in the network. Once created in one execution environment, it can transport its state and code with it to another execution environment in the network, where it resumes execution.

Shah 6

2.1.3 Mobile Agents and Mobile Agent Environment A mobile agent must contain all of the following models: an agent model, a life-cycle model, a computational model, a security model, a configuration model and finally a navigation model. A working definition of a mobile agent can be given as follows (Jain, Anjum, and Umar 2000): “A mobile agent consists of a self-contained piece of software that can migrate and execute on different machines in a dynamic networked environment, and that senses and (re) acts autonomously and proactively in this environment to realize a set of goals or tasks.” The software environment in which the mobile agents exist is called mobile agent environment. Following is the definition of mobile agent environment (Mahmoud 2001): “A mobile agent environment is a software system distributed over a network of heterogeneous computers. Its primary task is to provide an environment in which mobile agents can execute. It implements the majority of the models possessed by a mobile agent.” The above definitions state the essence of a mobile agent and the environment in which it exists. The mobile agent environment is built on top of a host system. Mobile agents travel between mobile agent environments. They can communicate with each other either locally or remotely. Finally, a communication can also take place between a mobile agent and a host service.

Shah 7

2.1.4 Brief comparison of Mobile Agent paradigm to the traditional Client-Server paradigm Today, client-server paradigm enjoys various techniques like remote procedure calling (RPC), remote object-method invocation (like Java RMI or CORBA) etc. The RPC paradigm, for example, is the prominent technique of the client-server paradigm. It views computer-to-computer communication as enabling one computer to call procedures in another (White 1996). Each message that the network transports either requests or acknowledges a procedure’s performance. Two computers whose communication follows the RPC paradigm have to agree upon the effects of each remotely accessible procedure and the types of its arguments and results. This agreement constitutes a protocol. For an example, as shown in Figure 2.1 (White pg. 7), a client computer initiates a series of remote procedure calls with a server in order to accomplish a task. Each call involves a request sent from client to server and a response sent from server to client. Thus the salient feature of client-server paradigm is that each interaction between the client and the server requires two acts of communication. That is, ongoing interaction requires ongoing

communication.

Shah 8

Remote Interactions Client App.

Server App.

User

Remote Server

Figure 2.1. Communications using client-server paradigm.

Local Interactions Mobile Agent Mobile Agent Server App.

User

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) Agent (FullTcp) recv(bytes)

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 TimerHandler

Application/TcpApp/Context

Figure 4.5. Class hierarchies for the model.

Shah 42 • Mobile Agent: MAgent class implements the basic functionalities of mobile agents like starting the agent after creation or arrival at a context, dispatching the agent to a remote context, disposing itself after completion of task, deactivating for a certain period of time, and cloning to make a copy of itself. It also provides certain abstract methods to be implemented by the class extending MAgent. These methods are the agent’s entry point method run(), and certain other provided for agent’s initialization and actions pertaining to certain conditions like before dispatching, after arrival, before cloning etc. There are three objects provided to listen to various events caused by agents viz. mobility, persistency and clone listeners. Their job is to listen to the corresponding agent events and invoke the matching actions.

As MAgent class contains some abstract methods, it cannot be instantiated. To instantiate an agent object, one must extend from the MAgent class. To facilitate this extension in both C++ and OTcl, a new class named MAgentInst is created by inheriting from MAgent class. It is actually this class’s object that shadows with the OTcl class MAgent. It is used to create a default implementation of all the abstract methods in MAgent class to call the corresponding method in OTcl and thus allowing extending the MAgent class directly in OTcl. Figure 4.6 tries to demonstrate the relationship between different classes mentioned above.

Shah 43

TcpApp extends Context contains

AppData extends MobileAgentData

contains contains MAgent

MobilityListner

contains contains

CloneListner

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

otcl class hierarchy

C++ class hierarchy

TclObject

Application

Process

Application/TcpApp

Application

Application/TcpApp/Context

Context

-o256 Application/TcpApp/Context otcl Shadow Object

context_ 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; } if(strcmp ( argv[1], "dispatch")==0) { dispatch(); 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: // makes the corresponding call to C++ method // call is handled OK

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_ data_size_ Represents the size of the code and data of a mobile 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_ homenode_ context_ Name of the current node of execution Name of the originating node 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_ enable_ Name of the node on which the context exists. 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 () void addPersistencyListener() void addCloneListener() void removeMobilityListener() void removePersistencyListener() void removeCloneListener() void startCreatedAgent (const char*, Context*, int ) void startArrivedAgent (Context* ) void startRetractedAgent (Context* )

Adds respective listeners that will listen to corresponding activities of the agent

Removes the corresponding listeners that are no more required.

Starts the agent after the corresponding events like creation, arrival to a new context and retraction from a remote context

respectively.

The following functions are also defined by the class MAgent, but are intended to be over-ridden by the classes deriving from MAgent. • onCreation() – User can over ride this method if it is requires to initialize the mobile agent with specific information. This over-ridding can be done either in C++ or in OTcl as discussed above.

Shah 54 • onDisposing() – As name suggest this method is called when an agent is about to dispose off. Override this method if it is required to do some clean up before the agent is deleted. • run() – This is the main entry point method for the agent. The code written in this method actually characterizes the agent. This is the method invoked by the context when an agent is created or migrated to a new node. Unlike all other methods mentioned above, it is compulsory to override this method as it determines the task of your agent. 4.3.6 Mobile Agent’s Event Listeners As shown in Figure 4.6, a mobile agent object can have three listeners depending on user’s requirement. User can add or remove them dynamically using methods shown in Table 4.3 like addMobilityListener(),

removeMobilityListener() etc. This listeners also provide certain methods that user can override in order to make the mobile agent do certain actions at a certain time. Their job is to listen to the current state of the mobile agent and whenever the state changes, invoke a corresponding method. Some of this methods includes: • onArrival() - The mobility listener object calls this method whenever the mobile agent arrives at a new context. In our model the overhead of agent loading can be accounted here. • onDispatching() and onReverting() – They are also triggered by the mobility listener object when the corresponding event happens i.e. before

Shah 55 dispatching of the agent to a new context and before reverting an agent from a remote context to the current context. • onCloning() – The clone listener object invokes this method just before the agent is required to clone. • onClone() and onCloned() – They are also triggered by the clone listener object for initialization of the newly created object and for implementing any functions required to be done on agent that has undergone cloning respectively. 4.3.7 Purpose and Functioning of MAgentInst class The class MAgentInst inherits from MAgent. But this class does not add any functionality to the mobile agent. It just provides a default behavior for all the abstract methods of the base class and that behavior is to invoke the corresponding methods of OTcl. Thus the purpose of MAgentInst class is to provide a user an OTcl interface for the abstract methods so that he can instantiate mobile agent objects and override whatever methods he needs, directly from OTcl without extending MAgent class in C++. This plays a very important role in providing the flexibility of implementing the agent’s behavior in either C++ or OTcl or in both. Following is an example of how this binding is done between C++ and OTcl. Here the abstract run() method, which is entry point method for an agent is implemented. In the implementation the corresponding run() method of OTcl interpreter is invoked using Tcl instance.

Shah 56 // "Bring-back-to-life" method // context - reference to context in which the current agent is executing void MAgentInst :: run ( Context* context) { Tcl& tcl = Tcl::instance(); // getting the OTcl interpreter instance

// Interpreter instance is necessary for any calls made from C++ to OTcl tcl.evalf ("%s run %s", name(), context->name()); // calling the corresponding run() method in OTcl of class represented by // name() i.e. the current agent and context’s name as an argument } It is important to note here that if the user is not extending MAgent class in C++, he is required to implement the run() method in OTcl. This is because in OTcl the “run” method is not defined. This is not the case with all the other methods available for overriding in OTcl as their default definition is provided in OTcl..

4.3.8 Methods Implemented in class Context Context provides services to the mobile agents and also maintains a hash table of agents currently registered with it. The context is responsible for actual transfer of the agents as well as agent’s creation. Table 4.4 shows the prototype of the important methods implemented along with their functions.

Shah 57 Table 4.4. Methods implemented in Context class void process_data(int, AppData* ) It over-rides the behaviour of TcpApp and is the principle method for processing the incoming agent. It retrieves the agent’s reference stored in the MobileAgentData and loads and starts the agent by calling agent’s startArrivedAgent() method. void retractAgent(const char*) It is used to draw back the agent from a remote site void registerAgent(MAgent*, int) As name suggests, it is used to initialize the agent and register in the agent’s table. void disposeAgent (int) void startAgent (const char* , int) It just erases the agent from the table. 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

ns-2

Otcl

Tclcl

tcl

Makefile.in

tcp

apps

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] $agent_ set code_size_ 5000 $agent_ set data_size_ 1000 $agent set m_factor_ 0.000001 $agent set create_delay 0.01 $agent set process_delay 0.1 $agent_ set selectivity_ 0.6 ;# creates agent instance ;# setting agent’s code size (in bytes) ;# setting agent’s data size (in bytes) ;# setting marshalling factor (sec/bytes) ;# agent’s creation time (in sec) ;# agent’s processing time (in sec) ;# 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 11 OTcl Interpreter

2

4

10 3 7 Context 1 (context1_)

5

Mobile Agent (agent_)

6

Other ns modules

9

Context 2 (context2_)

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

The code given above is not a full simulation script, as it does not include creating simulator instance, nodes, links etc.

2

Shah 67

Table 4.5. Sequence of Interactions Interaction Seq. # 1 2 3 4 5 6 7 8 9 10 11 Procedure Called start-agent() createAgent() startCreatedAgent() run() dispatch() move() send() process-data() startArrivedAgent() run() 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; recv_agent_->attachApp(this); 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. // attaches the recv_agent to itself // attaches itself to the recv_agent

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

Input Parameters

Mathematical Model

Simulation Model

Output Data

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 code_size_ data_size_ Values 10000 bytes 5000 bytes

status_size_ 0 bytes req_size Average Throughput Latency 1000 bytes 80,976 bytes/sec or 647.81 Kbps 20 ms

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

Throughput (Bytes/sec)

Selectivity of the Agent

Figure 4.11. Variation of throughput with agent’s selectivity

0.7

0.6

Time Required for the Interaction

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

Selectivity 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Mean

Simulation Model Output (Xi) 0.57737602 0.56009602 0.54281602 0.52585602 0.50857602 0.49129602 0.47401602 0.45705602 0.43976802 0.42248802 0.40521602 0.4913236 (Xmean) Percentage Difference

Mathematical Model Output (Yi) 0.637467 0.612768 0.58807 0.563371 0.538672 0.513974 0.489275 0.464576 0.439877 0.415179 0.39048 0.5139735 (Ymean) = |(Zmean/Ymean)* 100|

Difference Zi = Xi - Yi -0.06009098 -0.05267198 -0.04525398 -0.03751498 -0.03009598 -0.02267798 -0.01525898 -0.00751998 -0.00010898 0.00730902 0.01473602 -0.0226498 (Zmean) 4.406820

The exact validation of the model might be possible using the actual system data rather than that from mathematical model. But this was difficult to measure due to the unavailability of the resources and limited scope of this research. This can be considered as a part of the future work in further development of this simulation model.

Shah 78

CHAPTER-5 Simulating Wireless Applications Using Mobile Agent Model The Network Simulator NS2 along with the extension of mobile agent as described in the previous chapter is used to simulate certain basic wireless applications where the usage of the mobile agents is believed to be beneficial. The list of applications where the mobile agent paradigm may be used is given in section 3.3 of chapter 3. Out of all those applications, this study concentrates on the deployment of the mobile agent paradigm in information retrieval and also in middleware for providing service adaptation to a mobile device. The information retrieval application is studied for two different scenarios (section 5.1 and 5.2 respectively), both of which consist of a number of servers and a client looking for certain set of information. A brief study of the performance of mobile agent in the middleware is described in section 5.3 5.1 Information Retrieval- Scenario 1 The first scenario consists of a finite number of web servers (for example of different virtual enterprises) connected to the Internet and a mobile user (or client) looking for specific information (may be a particular product) from any one of these servers (Jain pg. 6). Figure 5.1 represents this scenario. It is assumed here that the user does not know on what server the information he is looking for is available. Each server is assigned a certain probability of having the requested

Shah 79 information. Thus, the user requires requesting each server serially until the information is found. The scenario is simulated using both client-server and mobile agent paradigm. In the client-server paradigm, the user device is required to pass the messages over the wireless link and through the base station on to the different

Server 1

Server 2 Mobile User Base Station

Server 3

Server n

Figure 5.1. Information retrieval - scenario 1.

servers. The result is also returned through the same path. This interaction is repeated with as many servers as required till the information is obtained. In mobile agent paradigm, the user device launches an agent with enough

Shah 80 intelligence to carry on the search for the required information on different servers until the task is completed, when the agent returns to the originating device with results. Thus, the agent is required to be transmitted over wireless link only twice. Figure 5.2 shows the picture representing this scenario as obtained from the Network Animator (“NAM” 1996). The current version of NAM does not support the visualization of the mobile node (user device) in wired-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] $err unit 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 } 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: ;# returning the model instance ;# new instance of error model ;# error introduction in unit of packet

Shah 82 # creating an instance of random number generator and seeding it set rng [new RNG] $rng seed 12345 # creating a uniformly distributed random variable that uses the RNG set u [new RandomVariable/Uniform] $u use-rng $rng $u set min_ 0 $u set max_ 1 # setting random probabilities between 0 and 1 to each server for {set i 0} {$i<$num_wired_nodes} {incr i} { set prob($i) [$u value] } # The following procedure simulates the finding of the information at a server proc is_info_found {count_} { global prob set rng [new RNG] $rng seed 67890 set v [new RandomVariable/Uniform] $v use-rng $rng $v set min_ 0 $v set max_ 1 set val [$v value] if { $val < $prob($count_) } {

Shah 83 return 1 } else { return 0 } } In mobile agent method, “run()” method is required to implement the agent’s behavior of launching to different servers in one by one until the information required is found. This is shown in the following code. # run {} method in the simulation script for scenario 1 MAgent instproc run {c} { $self instvar context_ homenode_ job_done_ global ns_ num_wired_nodes count_ latency opt context set node_ [$self node] set context_ $c if {$job_done_ == 0 } { if { $node_ == $homenode_ } { if { $count_ == 0 } { ;# current node visited ;# current context of execution ;# if task is not completed yet ;# if current node is homenode ;# if agent is just starting..

set dstcontext $context([expr $count_+1]) $context_ connect-to $dstcontext $self dispatch } else { record $self dispose ;# else agent is returned back without ;# any results ;# disposing itself

Shah 84 } } else { set job_done_ [is_info_found $count_] set count_ [expr $count_ +1] # if information not found dispatch to next node else dispatch to # home node if { $job_done_ == 0 && $count_ < $num_wired_nodes} { set dstcontext $context([expr $count_+1]) } else { set dstcontext $context(0) } $context_ connect-to $dstcontext $self dispatch } } else { record $self dispose return } ;# end of outer if-else } ;# end of run() In client-server method, the implementation of this scenario is a bit more complex. This is done mainly by writing small procedures for sending request and reply. The receipt of a request or reply is notified by the invocation of ;# if information is found and agent ;# returned to home node

Shah 85 procedure passed as an argument to the TcpApp application while sending the data. This procedure in turn can be implemented to process the request or reply. For example a client can send a request to any server as follows: proc send-request { } { global ns_ server_rcv user_snd count_ user_app server_app opt $ns_ connect $user_snd $server_rcv($count_) $server_rcv($count_) listen $user_app connect $server_app($count_) $user_app send $opt(req_size) "process-request" } This will result in the invocation of the procedure named “process-request” after the transmission of number of bytes given by opt(req_size) is done. Further, this procedure can be implemented as below. proc process-request { } { puts "Replying now...." send-reply } The procedure send-reply similarly sends required bytes and provides a name of the procedure to be invoke (process-reply). In “process-reply” client will check whether the required information is obtained or not and if not, it will make request to next available server. This scenario is studied by varying different network as well as agent’s parameters to evaluate the performance of mobile agent paradigm in different

Shah 86 situations and also to compare it with the corresponding client-server paradigm. On the other hand some parameters are kept constant in all the cases. For example, size of the request and reply for a single interaction with the server is fixed at 5000 bytes each, while the data size and selectivity of the agent is fixed to 5000 and zero respectively. The selectivity value here suggests that the possibility of remote filtration of the results by the agent is not considered. Similarly the link parameters like bandwidth and delay are kept the same in all cases for both the wired (2 MB, 10ms) and wireless connections 10ms). (500 KB,

The different cases thus studied are described in the following

subsections along with their results. 5.1.1 Ideal Conditions for Mobile agent Systems with No Overhead The first case considers the ideal conditions for mobile agent system, which assumes no other overhead caused by the use of agent paradigm. Thus all the overhead parameters like time for agent’s creation (create_delay_) and agent’s marshalling and unmarshalling time (m_factor_) are set to zero, i.e. their default values. Also the total size of the agent is set equal to the size of request and reply for the corresponding client-server paradigm. Thus, no size overhead is considered. In this simple case, the total time required by the query from the mobile user is measured at different wireless network conditions by varying the probability of packet loss from 0 to 0.5 on the wireless link. Simulation does not work at packet loss rate higher than 0.5 because of the retransmission problems encountered as a result of modification in FullTcp as described in section 4.7.

Shah 87

Figure 5.3. Performance comparison- ideal conditions

Figure 5.4. Performance ratio mobile-agent/client-server.

Shah 88 The results obtained from both the methods are shown in Figure 5.3. It can be seen from the figure that the results are exactly what one would expect. At low packet loss rate the performance by both methods is similar. But as the packet loss rate increases, the performance of the client-server method degrades exponentially while that of mobile agent method is not affected much. This is because the mobile agent method does the least use of the wireless link in compare to client-server method. Further at some higher packet loss rate, the time required for agent paradigm also increases exponentially as the number of re-transmissions required increases rapidly. Finally, after a certain point no more transmission is possible and all the packets are dropped. Figure 5.4 tries to show the same conditions in a different perspective in the form of performance ratio of mobile agent to client-server technology. It can be seen that the performance ratio rapidly increases initially along with loss in wireless networks and finally tries to stabilize after a certain point. These results clearly show the effectiveness of the mobile agents in this type of applications. But the actual deployment of mobile agents cannot provide such an ideal performance mainly because of the several overheads. 5.1.2 Effect of the Mobile Agent’s Size Overhead Mobile agent’s size may play a considerable role in degrading its performance especially on a low bandwidth connection typical of wireless networks. Hence it is important to study the agent’s performance in terms of its varying size. In this case the size of the agent is varied in multiple of the original size used in the first case. Again the parameter measured is the time required for

Shah 89 completion of the query. The client’s request and reply sizes are not changed. As the size of the agent’s code increases, the processing time for the agent on the remote server may also increase. It is assumed that this processing time is directly proportional to the size of the agent’s code. Figure 5.5 shows the results in this case with the agent’s size varying from 5000 bytes to 25,000 bytes and packet loss rate is fixed at 0.15. It can be seen from the figure that the performance benefits of mobile agents is substantial only up to certain agent’s code size (around 15 KB) and after that the client-server method shows much better performance. This shows the severe impact of agent’s size on its performance. The client-server method is not affected here as its request or reply sizes are not changed and hence gives a constant time.

Figure 5.5. Performance comparisons with variable agent code size.

Shah 90 5.1.3 Effect of Creation and Marshalling/Serialization Overhead Another important factor in degrading the performance of a mobile agent is the overhead caused by the time required for agent’s creation and the time required for agent’s packing of code, data and status at the dispatching node and unpacking at the receiving node. Both depend on the actual implementation of the mobile agent system and also the type and size of agent’s data. For example, agent’s creation time will be different for a mobile agent system forking a new process (or may be an interpreter) for each agent created compare to one who uses an existing process or just need to fork a new thread. This creation time for different agent systems is measured in the previous experiments (Dikaiakos pg. 18) and is available. In the similar way, agent’s packing time will be different for those using marshalling compared to some java-based systems using serialization. The marshalling overhead further will increase with the overall size of the agent. The factor representing this overhead (m_factor_) is assumed to be linearly proportional to the size. The marshalling factor further also depends on the type of data to be packed (mainly for serialization). For measuring this factor for certain Java data types, a class called SerializeTest (“SerializeTest” 1998) is used. This is a simple code written in java to measure the memory and time requirements for serializing different Java data types. With the help of this program, m_factor_ for a vector of integers is determined.

Shah 91

Figure 5.6. Performance comparisons with system overhead.

In this case also, the total query time is measured by varying the probability of loss over wireless link. But here the agent’s creation time and marshalling/unmarshalling time is taken into consideration. The size of the

agent’s code is fixed at 8 KB and its time for creation is taken as 0.1 sec. The marshalling factor value obtained from SerializeTest (using P4 2.0 GHz desktop with 512 MB RAM running Windows 2000) is 0.00000266 sec/byte or 2.66 ms/KB. Figure 5.6 represents the results obtained in this case for all the three data types. It can be seen from the figure that the mobile agent system no longer provides performance benefits at a lower loss rate (up to 0.2), as was seen before in Figure 5.3. This denotes considerable overhead of agent’s system delays. Also the overhead for different data types required to serialize may also

Shah 92 slightly differ. Thus, particularly for this case, it can be said that the mobile agents are useful only when the probability of loss over wireless link is more than 0.22 for most of the data types.

5.1.4 Effect of Number of Servers Required to Visit Finally, it is also important to study the performance of mobile agent and client-server paradigm under the effect of variable number of servers required to visit in order to complete the task. In all the cases discussed above, the number of servers was fixed by seeding both the random number generators i.e. one assigning the probability of having information and the other simulating the findings of the information. This was done to generate the same output for comparison purposes. But now it is required to vary the number of servers. So random number generators are not required. Figure 5.7 shows the results for this case. It is clear from the graph that the mobile agents are useful only if the number of servers required visiting for a particular task or query is more than 3 for the given conditions. It should be noted here that the results heavily depend on the input parameters and change in any of them may considerably change the mobile agent’s performance.

Shah 93

Figure 5.7. Performance comparisons with variable number of servers.

Shah 94

5.2 Information Retrieval- Scenario 2 In this scenario, consideration has been given to the fact that number of interactions with the successive server in a list of servers to be visited may depend on the results obtained from the previous server. For example, consider a tourist with a mobile device requiring information about the hotels available in the town to visit. For getting such a list of hotels, he may query a database registering all the hotels for that town. Now suppose that for each hotel on the list, he wants to inquire about the rate, for example, with his travel agency’s database. It is assumed that these two databases are managed on different machines, by different companies. Thus, the first server provides an interface to obtain a list of hotels for the given name of the town, while the second server provides an interface to return the rates for the given hotel name. This scenario can be analyzed in terms of both client-server and mobile agent methods. In client-server method, the client’s query to the first server for getting the list of hotels can be completed using only one RPC call. But once the list is obtained, the client will have to make one RPC call for each hotel in the list to the second server. Thus, the total cost of communication can be given as the sum of one RPC call to server 1 plus n calls to server 2, where n is the number of hotel records return from query to first server. In the mobile agent method, the tourist dispatches an agent to the first server with its request for hotel list. The agent queries the database locally at server 1 and stores the hotel list. Next, it moves to server 2 where it can make local invocations to find out rates information for all the hotels in the list. Finally, with

Shah 95 all the results stored in it, the agent returns back to the tourist’s mobile device. Thus this method needs agent to be dispatched only three times; whatever may be the number of records n retrieved from the first server.

Figure 5.8. Performance comparisons- scenario 2.

Table 5.1. Parameter Values for Scenario-2 Parameters code_size_ err_rate m_factor_ Values 10 KB 0.15 0.0000026

create_delay_ 0.1 req_size 1 KB

Shah 96 As the total time required for the completion of task in client-server method depends heavily on the number of records retrieved from the server 1, the simulation is performed by varying this parameter from 1 to 50 records. Each record is assumed to be of same size of 100 bytes. The parameters used for this simulation are shown in Table 5.1 and the results obtained are visualized in Figure 5.8. The figure shows that the mobile agent method is not much efficient for a small number of records (around 7). But as the number of records increases from there, the mobile agent provides much more better performance compare to the client-server method. The initial lower efficiency is mainly contributed to all the overheads considered in section 5.1. Thus the number of records at which the cross point is obtained depends heavily on the agent’s size and the agent system’s overhead. 5.3 Mobile Agents in Middleware for Mobile Device The importance of middleware in providing the support to mobile devices is widely accepted now. This section focuses on the study of such a middleware implemented using mobile agent paradigm and compares it with the more traditional client-server based middleware communication mechanisms like RMI, CORBA, etc. The application considered here consists of the adaptive services provided by the middleware to adapt the contents received by the mobile devices. These services may include 1) dynamic content adaptation depending on the type of mobile device used to access the Internet, 2) filtering of some additional data (e.g. images) that may not be important to the user, 3) compression of the data to improve the throughput over wireless networks etc.

Shah 97

Internet Server

Traditional Middleware

Internet Server

MA Home

Gateway

Gateway MA based Middleware Base Station

Base Station

Mobile Device

Mobile Device

Figure 5.9. Traditional and mobile agent based middleware

Figure 5.9 shows the scenario for both client-server and mobile agent (MA) based middleware. The client-server based middleware is assumed to be somewhere in the Internet infrastructure while MA based middleware is located in the gateway between wired and wireless networks. Each mobile device is associated with a mobile agent executing in the MA based middleware providing services to that particular mobile device. Whenever the mobile device moves from one domain to another, the corresponding mobile agent is also required to be moved to the gateway machine in the new domain. Thus, the mobile agent follows the movement of the mobile device. This is simulated by retracting user’s

Shah 98 Table 5.2. Parameter Values for Simulating Middleware Parameters rep_size_ Values 50 KB

selectivity (applicable 0.5 to both C/S and MA) m_factor_ create_delay_ req_size Bandwidth (Wired) Bandwidth (Wireless) 0.0000026 0.1 5 KB 1 MB 1 MB

agent from agent’s home node for the user’s first request to the server. The parameters used for this simulation are given in Table 5.2. Figure 5.10 shows the results of the simulation under four different conditions. The first bar represents a very simple condition in which the mobile device is located in the home domain only and hence its corresponding mobileagent is not required to migrate. The performance for this condition obviously will be optimum compared to client-server based approach for middleware. This is because of the extra routing of data packets through the middleware located elsewhere in the Internet in C/S architecture while MA middleware is located right near the mobile device on the gateway and hence no extra routing is required. But the performance of MA middleware degrades whenever the mobile device moves to another domain. This is because of the time required for mobile agent

Shah 99 migration to remote domain’s gateway and hence the performance now depends heavily on the size of the agent that is required to be transmitted. Thus the performance is now a tradeoff between extra routing of data in C/S and size of the agent to be transmitted in MA paradigm. The third bar in Figure 5.10 represents the MA paradigm for agent size of 5 Kbytes while the fourth bar for the size of 10 Kbytes. It can be seen here that C/S performs better than MA even at an agent’s size of only 10 Kbytes.

2.5

Total Time Required (sec)

2 1.5

1 0.5

0
MA-No Migration Client-Server MA-Size 5 K MA-Size 10 K

Figure 5.10. Mobile agent / Client-server comparisons

It is important to note here that the performance measure above is only for the first interaction between the mobile device and the server. As the number of interactions increases, the MA’s performance should improve. The reason is that

Shah 100 the migration of agent to remote domain is required only once, i.e. for the first interaction and not for any subsequent interactions. Figure 5.11 shows the simulation results proving the above argument. Here the total time required is measured for variable number of interactions with agent’s size of 10 Kbytes and 50 Kbytes. The figure shows that even for agent’s size of 50 Kbytes, the performance will be better than the C/S paradigm if number of interactions is more than 3, which will be true for many practical situations.
12

10

Time Required (in sec)

8

6

4

2

0 1 2 3 4 5

Number of Interactions

MA Size 10 KB

MA Size 50 KB

Client-Server

Figure 5.11. Effect of number of interactions Thus, mobile agents may have some performance benefits over C/S middleware. But this is not the only reason for deploying mobile agents in a middleware for mobile devices. The effectiveness of mobile agents in middleware is revealed in their ability (Bellavista 26). to provide user, terminal and resource mobility

Shah 101 5.4 Overall Analysis of the Results The overall analysis of the results obtained from the study of various application scenarios considered here can lead to the following inferences: • The results obtained in scenario cases described in section 5.1.1 and 5.2 are similar to the earlier results for similar scenarios given in (Jain pg. 6) and (Ismail pg. 19) respectively. This shows the efficiency of the simulation model in analyzing the mobile agent applications. • The performance of the mobile agent technology in wireless applications heavily depends on various network parameters like available bandwidth and reliability of the network, as well as agent parameters like agent’s code and data size, execution environment, number of migrations required, etc. • As proposed, mobile agents do have better performance as compared to client-server techniques in the considered applications, but this is not always true. Under certain conditions such as reliable network connections, large size of the agent code, small number of servers to query, etc., client-server will perform much better than the mobile agents. The parameter values that may lead to such conditions can be determined very easily by performing simulation test for the given scenario. This is shown in sections 5.1 and 5.2 above where such parameter values were determined using the simulation results. The above inferences can help mobile agent dynamically choose the method of interactions based on current network and agent characteristics as follows.

Shah 102 The simulation results can provide the information about the performance likely to obtained for the current set of parameter values. This information can be provided to the agent to help it choose dynamically whether to go for migration or interact remotely using traditional client-server techniques like RPC or RMI. For example, it is possible to create a stationary service agent that can store the results obtained from the simulation for various conditions and also can provide interface to the application agents to query this information. Before going for migration, the agent can query this service agent and can decide what will be more efficient, either to dispatch or to make remote invocations.

check_performance( ) Shall_I_Migrate (agent_params) Mobile Agent Service Agent

reply ‘yes’ or ‘no’

reply =‘yes’ true

false

use_RMI()

dispatch() Figure 5.12. An example usage of a service agent storing simulation results.

Figure 5.12 shows an example of deploying such a service agent. The mobile agent queries the service agent using a method like shall_I_Migrate().

Shah 103 The service agent further determines the performance likely to obtained using simulation results for the given agent and network parameters and replies with either yes or no. The mobile agent decides whether to dispatch or not with the help of this reply. To further illustrate the performance optimization using above concept, lets consider again the scenario conditions given in section 5.1.2 where the effect of agent’s code size is studied. According to the results obtained in that section, the optimum performance can be obtained if the mobile agent migrates only when its code size is less than 15,000 bytes. Thus if code size is more than 15000 bytes, the mobile agent may choose to do remote messaging with service agents rather than migrating to the remote node. Figure 5.13 shows the results obtained from simulation in this case. The curve represented by “optimum” shows the results obtained for such a mobile agent using above optimizations.

Figure 5.13. Performance optimization using simulation results

Shah 104 The fact that the mobile agent technology is not always efficient supports the concept of integration of the mobile agent technology with other software development tools rather than its sole use for application deployment. The mobile agent technology should be presented to the application programmer as another useful tool in the set of tools available for creating robust applications. Thus, an application developer may choose to use mobile agent technology for some applications and client-server technology for others.

Shah 105

CHAPTER-6 Conclusion and Future Work 6.1 Conclusion This thesis addresses the issue of performance analysis of mobile agents in real-world wireless applications using simulation. We have developed a very simplified but effective simulation model to study the appropriateness of mobile agents in any real-world application. This model is implemented by extending the general-purpose network simulator NS2. The simulation model thus implemented is used to study the behavior of mobile agents in some important wireless Internet applications where they are believed to have better performance. The analysis of the results thus obtained shows that although the mobile agent provides performance benefits over traditional client-server techniques, this is not true under all the conditions. Such conditions have been discussed. The major parameters on which the performance of mobile agents depends are also presented. Furthermore, it is proposed that the favorable and unfavorable conditions thus determined could be provided to the agent to help it dynamically decide whether to employ migration or to execute client-server interactions in a traditional way. Also, the results obtained from the simulation studies support the current trend of integrating the mobile agent technology into the mainstream of industrial software development rather than treating it as an exotic and specialized offshoot.

Shah 106 6.2 Future Directions The work done in this thesis has provided a broad base for studies particularly in deploying the mobile agent technology in real-world applications. The simulation model developed here may provide a stepping-stone for those wanting to study the mobile agent technology with availability of only limited resources. This section tries to point out what can be future extensions to the contributions made in this thesis. The mobile agent model implemented here simulates the most basic behavior of agent technology. Many complex matters have not been considered. Hence the future work could include the following possible extensions to the model: • Only one type of agent’s migration is implemented, in which all the classes/code associated with an agent has been transmitted. This can be extended to support other techniques like dynamic class loading on demand. • The support for simulating an agent’s code caching may be provided. It may result in substantial performance benefits when dealing with multiple agents. • The model may be extended to support the simulation of services specific to the mobile devices. These may include 1) provision of docking station, that facilitates the disconnected operations using mobile agents, and 2) provision of moving proxies, that follows the movement of the mobile device in the corresponding wired network. The moving proxies can

Shah 107 provide personalized services and QoS adaptation and tailoring to the mobile device. • Future work for the mobile agent model could also include the model’s validation with actual system data if available. Similarly, the wireless applications studied here are only some of the fundamental applications well known for deploying the mobile agent technology. There are many other applications where mobile agent technology seems to be promising and can be further studied. These include but are not limited to: • Provision of QoS for wireless multimedia applications where the mobile agent may be in the form of a user’s proxy moving along with the mobile user in the corresponding wired network and may provide dynamic service adaptation and tailoring to the user device depending on the device and network constraints. • Provision of personalized services to the portable device that uses the same proxy based approach to provide information based on the user’s profile. • Wireless distributed E-commerce applications; for example, banking services for portable devices.

Shah 108

REFERENCES “ACTS”. 1999. AC346: Agent Based Mobile Access to Information Services (AMASE). Advanced Communication Technologies and Services [accessed 12 April 2003]. Online. Available from http://www.cordis.lu/infowin/acts/rus/projects/ac346.htm. “IBM”. 1998. Aglets: Mobile Java Agents. IBM Tokyo Research Lab [accessed 1 November 2002]. Online. Available from http://www.trl.ibm.com/aglets. “Marc Greis”. 1998. Marc Greis’ Tutorial for the Network Simulator NS [accessed 1 December 2002]. Available from http://www.isi.edu/nsnam/ns/tutorial/. “NAM”. 1996. The Network Animator [accessed 15 January 2003]. Available from http://www.isi.edu/nsnam/nam/. “NS2”. 1996. The Network Simulator ns-2 Documentation [accessed 1 December 2002]. Available from http://www.isi.edu/nsnam/ns/ns-documentation.html. “SerializeTest”. 1998. SerializeTest to measure serialization overhead; [accessed 05 June 2003]. Available from http://www.sosnoski.com/Java/Timings.html. Bandyopadhyay, Somprakash, and Krishna Paul. 1999. Evaluating the performance of mobile agent-based message communication among mobile hosts in large adhoc wireless network. In Proceedings of the Second ACM International Workshop on Modeling, Analysis and Simulation of Wireless and Mobile Systems (August ):69-73.

Shah 109 Baschieri Francesco, Paolo Bellavista, and Antonio Corradi. 2002. Mobile agents for QoS tailoring, control and adaptation over the Internet: The ubiQoS video on demand service. IEEE 2002 Symposium on Applications and the Internet :109-118. Bellavista, Paolo, and Antonio Corradi. 2002. The ubiquitous provisioning of Internet services to portable devices. IEEE Pervasive Computing (July/Sept):8187. Breslau, Lee, Deborah Estrin, and Kevin Fall. 2000. Advances in network simulation. IEEE Computer, vol. 33, no. 5:59-67. Brewington, Brian, Robert Gray, Katsuhiro Moizumi, David Kotz, George Cybenko, and Daniel Rus. 1999. Mobile agents in distributed information retrieval. Chapter 15 in Intelligent Information Agents, edited by M. Klusch. Berlin: Springer Verlag. Chess, David, Colin Harrison, and Aaron Kershenbaum. 1995. Mobile agents: are they a good idea? IBM Research Report, NY. Chung, Jae, and Mark Claypool. 2000. NS by Example. Worcester Polytechnic Institute [accessed 1 Feb 2003]. Available from http://nile.wpi.edu/NS/. Dikaiakos, Marios, and George Samaras. 2000. Quantitative performance analysis of mobile agent systems: A hierarchical approach.” Technical Report, TR-00-2, Dept. of Computer Science, University of Cyprus. Gray, Robert, David Kotz, and Ronald Peterson. 2001. Mobile agent versus Client/Server performance: Scalability in an information-retrieval task.” In

Shah 110 Proceedings of the Fifth IEEE International Conference on Mobile Agents, Atlanta, Georgia, Springer-Verlag (December):229-243. Gray, Robert, David Kotz, Saurab Nog, Daniel Rus, and George Cybenko. 1996. Mobile agents for mobile computing. In Technical Report PCS-TR96-285, Dartmouth College. Hadjiefthymiades, Stathes, Vicky Matthaiou, and Lazaros Merakos. 2002. Supporting the WWW in wireless communications through mobile agents”. Mobile Networks and Applications, 7:305-313. Ismail, L., D. Hagimont, and J. Mossiere. 1999. Evaluation of the mobile agents technology: Comparison with the Client/Server paradigm. ACM SIGPLAN Notices, vol. 34, no. 10:306-313. Jain, Ravi, Farooq Anjum, and Amjad Umar. 2000. A comparison of mobile agent and Client-Server paradigms for information retrieval tasks in virtual enterprises. AiWoRC Workshop, Buffalo, New York (April). Kotz, David, George Cybenko, Robert Gray, Guofei Jiang, and Ronald Peterson. 2002. Performance analysis of mobile agents for filtering data streams on wireless networks. Mobile Networks and Applications, 7:163-174. Kotz, David, Robert Gray, and Daniel Rus. 2002. Future directions for mobile agent research. IEEE Distributed Systems Online [journal online]; September, [accessed 1 November 2002]. Available from http://dsonline.computer.org/0208/f/kot_print.htm.

Shah 111 Kotz, David, Robert Gray, Saurab Nog, Daniel Rus, Sumit Chawla, and George Cybenko. 1997. Agent Tcl: Targeting the needs of mobile computers. IEEE Internet Computing, vol. 1, no. 4 (July/August):58-67. Lange, Danny, and Mitsuru Oshima. 1998. Mobile agents with Java: The Aglet API. World Wide Web, vol. 1, no. 3:n.pag. ---. 1999. Seven good reasons for mobile agents. In Communications of the ACM, vol.42, no.3: 88-89. Law, Averill, and W. David Kelton. 2000. Simulation modeling and analysis. 3rd ed. New York: McGraw-Hill. Mahmoud, Q. 2001. MobiAgent: A mobile agent-based approach to wireless information systems. Proceedings of the 3rd International Bi-Conference Workshop on Agent Oriented Information Systems (AOIS-2001), Montreal. Milojicic, D.S., D. Chauhan, and W. laForge. 1998. Mobile Objects and Agents (MOA), design, implementation and lessons learned. In The Fourth USENIX Conference on Object-Oriented Technologies (COOTS) (April): 179194. Spalink, Tammo, John Hartman, and Garth Gibson. 1998. The effect of mobile code on file service. Technical Report TR98-12, Department of Computer Science, University of Arizona (November). Srasser, Markus, and Markus Schwehm. 2000. A performance model for mobile agent systems. In Proceedings of the Autonomous Agents 2000 Workshop on Agents in Industry, Barcelona, Spain (2000).

Shah 112 Sun Microsystems. 2002. Mobile Information Device Profile (MIDP). Sun Microsystems, Inc [accessed 1 June 2003]. Online. Available from http://java.sun.com/products/midp. Walsh, Tom, Noemi Paciorek, and David Wong. 1998. Security and reliability in Concordia. In Proceedings of 31st Hawaii International Conference on Systems Sciences, VII:44-53. White, James. 1996. Telescript technology: Mobile agents. In Software agents, edited by J.M.Bradshaw. Cambridge, MA: The AAAI Press/The MIT Press.

Shah 113

APPENDIX: User’s Guide to Mobile Agent Model A.1 Model Parameters Accessible Through OTcl The parameters of the mobile agent object that are accessible by the user are given in Table A.1. The default values of these parameters are defined in ~ns/tcl/lib/ns-default.tcl.

Table A.1. OTcl Parameters for Mobile Agent Object

Parameter Id_

Comments Agent’s Id that is unique among all the agents currently executing in all the contexts. It is assigned by the model whenever a new agent is created and hence should not be set.

code_size_

The size (in bytes) of the agent code that is required to be transmitted.

data_size_

The size (in bytes) of agent’s data that is required to carry away while migrating.

status_size_ The size (in bytes) of the agent’s current execution stack. This parameter will be zero for agent systems deploying weak migration.

Shah 114 Table A.1. OTcl Parameters for Mobile Agent Object, continued

Parameter rep_size_

Comments The actual size (in bytes) of the results expected from the interaction without considering the agent’s remote processing/filtering ability,

selectivity_

The factor by which the mobile agent reduces the size of the results (rep_size_) by remote processing or filtering.

m_factor_

The marshalling or serialization overhead (in sec/byte). This overhead can be obtained from experiments by measuring the time required to serialize and de-serialize a certain amount of data.

process_delay_ The processing time of the agent at a particular context (in sec). This can be also set as a factor proportional to the agent code size. Please refer to the C++ class MAgent for details. create_delay_ The time (in sec) required for creating a single agent. Please note here that no code caching is considered in this model. Hence the creation time will be the same for all the agents whatever number of them is created. This parameter is defined in OTcl only. homenode_ The home node for the mobile agent. This is set at the creation of the agent and is also defined only in OTcl.

Shah 115

A.2 Procedures Available to User Through OTcl These procedures consists of all the instance procedures implemented in an OTcl class as well as corresponding C++ shadow methods defined through command() method of C++ class.. The following is the list of C++ shadow methods available to the user through OTcl for the MAgent class. Shadow methods are shown in the form of OTcl instance procedures for realizing how they can be used as such procedures. Please see the simulation script given in section A.3 for their example usage. • MAgent instproc run arg1 :# entry point for the mobile agent that user

# is required to define to implement the mobile agent task. Please see # the simulation script given in A.3 for example. • • • • MAgent instproc context MAgent instproc node MAgent instproc is_active MAgent instproc dispose ;# returns the current context of execution ;# returns the current node of execution ;# checks the current state of the agent ;# deletes the agent object and detaches

# itself from the list of agents in the current context • MAgent instproc dispatch ;# dispatch to the context to which the current context is connected to. • • • • • MAgent instproc dispatch arg1 ;# dispatch to the context given by arg1

MAgent instproc deactivate arg1 ;# deactivation for time given by arg1 MAgent instproc clone ;# make an exact copy of the current agent

MAgent instproc removeMobilityListener MAgent instproc removeCloneListener

Shah 116 • MAgent instproc removePersistencyListener # removes the corresponding listeners On the other side the following three methods are defined only in OTcl part of class MAgent. • • • MAgent instproc addMobilityListener MAgent instproc addCloneListener MAgent instproc addPersistencyListener # adds the corresponding listeners

The following are the procedures available to the user for overriding in order to define certain tasks to be done at certain events. However, in order to use these event listeners, the corresponding listener must be added to an agent through the procedures mentioned above like ‘addMobilityListener’ etc. # User can override any of the following instance procedures in order to define # the task to be executed at the corresponding event.

# Class MobilityAdapter – For events related to mobility of the agent. MobilityAdapter instproc onArrival { } # on arrival of an agent to a new node MobilityAdapter instproc onReverting { } # on reverting from other node to the current node. MobilityAdapter instproc onDispatching { } # to do the finish work before dispatching to a new node

Shah 117 # Class CloneAdapter – For events related to agent’s cloning. CloneAdapter instproc onClone {} ;# executed on the newly created clone

CloneAdapter instproc onCloning {} ;# executed before cloning of an agent CloneAdapter instproc onCloned {} ;# executed on an agent that has undergone cloning.

# Class PersistencyAdapter – For evemts related to activation and deactivation #of the agent PersistencyAdapter instproc onActivation { } ;# invoked after agent is activated. PersistencyAdapter instproc onDeactivating { } ;# invoked before agent is deactivated.

The instance procedures available to the user for the class Context provides mainly with creation and maintenance of the agents and are given next. C++ shadow methods are as follows: • Context instproc start ;# starts the context after which it can create and # receive agents. Agents will not be received if the context is not started. • Context instproc shutdown ;# disable the context so that it does not provide support to any agents. • • Context instproc node ;# returns the node on which context is deployed

Context instproc getAgent arg1 # returns an OTcl agent object with Id given by arg1.

Shah 118 • Context instproc retractAgent arg1 ;# retract (pull) the agent with unique Id given by arg1 to the current context. • Context instproc startAgent arg1 arg2 # not for direct used., but is used by OTcl instance procedure # create-agent. Here arg1 represents the agent’s name and optional # arg2 represent a string that can be used to initialize an agent. The following two are the pure OTcl instance procedures that are defined only in OTcl class Context. • Context instproc create-agent arg1 arg2 # creates, initializes and executes an agent with name given by arg1. # The user is required to create an agent instance and invoke this # procedure as shown in example script (section A.3). • Context instproc connect-to arg1 # connects current context to the context given by arg1. This includes # connection at the application level as well as connection between # transport layer agents. This procedure should be invoked before calling # for agent’s dispatch.

Shah 119

A.3 An Example Script
# # # # # # # # # # # # # # # Script simulating the behavior of mobile agents in wired-cum wireless scenario as described in section 5.1.1 under ideal conditions for mobile agents. The scenario consists of 8 servers (wired nodes) and a mobile node acting as a client. The mobile node is connected to the wired network through a base station node. All the servers and the client node have a context or place for creating and executing agents. The context of mobile node creates and starts a mobile agent in order to accomplish an information retrieval task. For this task agent is required to migrate to different servers in turn and to look for the requested information. Each server is assigned a certain probability of having the information required. If the agent finds the information at any server, it returns back to the original mobile node and does not required to check any more servers. The performance of mobile-agent in terms of total time required to finish the task is measure for the given probability of loss over wireless channel.

####################################################################### #################### Code for Scenario Setup ########################## ####################################################################### #====================================================================== # Define options # #====================================================================== set opt(chan) Channel/WirelessChannel ;# channel type set opt(prop) Propagation/TwoRayGround ;# radio-propagation model set opt(netif) Phy/WirelessPhy ;# network interface type set opt(mac) Mac/802_11 ;# MAC type set opt(ifq) Queue/DropTail/PriQueue ;# interface queue type set opt(ll) LL ;# link layer type set opt(ant) Antenna/OmniAntenna ;# antenna model set opt(ifqlen) 50 ;# max packet in ifq set opt(nn) 1 ;# number of mobilenodes set opt(adhocRouting) DSDV ;# routing protocol set opt(x) 670 ;# x coordinate of topology set opt(y) 670 ;# y coordinate of topology set opt(seed) 0.0 ;# seed for random number gen. set opt(stop) 30 ;# time to stop simulation set opt(app_start) 10 ;# time to start the agent application set opt(err_rate) [lindex $argv 0] # rate of packet loss getting from command line set latency 0 # Measuring execution time requirement set num_wired_nodes 8 # total # of servers set num_bs_nodes 1 # number of base-station nodes # Setting bandwidth and delay for the MAC layer of wireless network Mac/802_11 set dataRate_ 500Kb Mac/802_11 set basicRate_ 500Kb

Shah 120
LL set delay_ 10ms # ======================================================================= # check for boundary parameters and random seed if { $opt(x) == 0 || $opt(y) == 0 } { puts "No X-Y boundary values given for wireless topology\n" } if {$opt(seed) > 0} { puts "Seeding Random number generator with $opt(seed)\n" ns-random $opt(seed) } proc DEBUG text { # Ouput debug text puts "DEBUG: $text" } # create simulator instance set ns_ [new Simulator] # create trace files set tracefd [open mobile-agent.tr w] set namtrace [open mobile-agent.nam w] # use new trace from CMU $ns_ use-newtrace $ns_ trace-all $tracefd $ns_ namtrace-all $namtrace # set up for hierarchical routing $ns_ node-config -addressType hierarchical AddrParams set domain_num_ 2 ;# number of domains lappend cluster_num 10 1 ;# number of clusters in each domain AddrParams set cluster_num_ $cluster_num lappend eilastlevel 1 1 1 1 1 1 1 1 1 1 2 ;# number of nodes in each cluster AddrParams set nodes_num_ $eilastlevel ;# of each domain

# Create topography object set topo [new Topography] # define topology $topo load_flatgrid $opt(x) $opt(y) # create God create-god [expr $opt(nn) + $num_bs_nodes] #create wired nodes set temp {0.0.0 0.1.0 0.2.0 0.3.0 0.4.0 0.5.0 0.6.0 0.7.0 0.8.0 0.9.0} ;# hierarchical addresses for wired domain for {set i 0} {$i < $num_wired_nodes} {incr i} { set W($i) [$ns_ node [lindex $temp $i]] }

Shah 121

# new way of configuring wireless channel set chan [new $opt(chan)] # configure for base-station node $ns_ node-config -adhocRouting $opt(adhocRouting) \ -llType $opt(ll) \ -macType $opt(mac) \ -ifqType $opt(ifq) \ -ifqLen $opt(ifqlen) \ -antType $opt(ant) \ -propType $opt(prop) \ -phyType $opt(netif) \ -channel $chan \ -topoInstance $topo \ -wiredRouting ON \ -agentTrace ON \ -routerTrace OFF \ -macTrace OFF $ns_ node-config -OutgoingErrProc UniformErr # introdue the error-model to simulate packet loss in the outgoing # packets of the wireless channel proc UniformErr { } { global opt set err [new ErrorModel] $err unit packet set rng [new RNG] $rng seed 1 $err ranvar [new RandomVariable/Uniform] $err set rate_ $opt(err_rate) return $err } #create base-station node set temp {1.0.0 1.0.1 1.0.2 1.0.3} 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<$num_wired_nodes} {incr i} { set prob($i) [$u value] } # Simulation the findings of the information at a particular server # based on its probability. proc is_info_found {count_} { global prob set rng [new RNG] $rng seed 67890 set v [new RandomVariable/Uniform] $v use-rng $rng $v set min_ 0 $v set max_ 1 set val [$v value] if { $val < $prob($count_) } { return 1 } else { return 0 } } # Tell all nodes when the simulation ends for {set i } {$i < $opt(nn) } {incr i} { $ns_ at $opt(stop).0 "$node($i) reset"; } $ns_ at $opt(stop).0 "$BS(0) reset"; $ns_ at $opt(stop).0002 "puts \"NS EXITING...\" ; $ns_ halt" $ns_ at $opt(stop).0001 "stop" # close all the trace files while stopping the simulation proc stop {} { global ns_ tracefd namtrace f0 $ns_ flush-trace close $tracefd close $namtrace close $f0 } puts "Starting Simulation..." $ns_ run ;# finally run the simulation. ############################# End of Script ########################## #######################################################################