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.
TABLE OF CONTENTS
LIST OF TABLES vii LIST OF FIGURES viii
CHAPTER-1 1
Introduction 1
1.1 Motivation 2
1.2 Performance Analysis using Simulation 3
1.3 Organization of the Thesis 3
CHAPTER-2 5
Background and Literature Survey 5
2.1 Overview of Mobile Agents 5
2.1.1 A Software Agent 5
2.1.2 Mobile vs. Stationary Agents 5
2.1.3 Mobile Agents and Mobile Agent Environment 6 2.1.4 Brief comparison of Mobile Agent paradigm to the traditional Client-
Server paradigm 7
2.1.5 What Mobile Agents can do for us? 9
2.2 Survey of Mobile Agent Systems 11 2.2.1 Java-based systems 11 2.2.2 Multiple Language Systems 12 2.2.3 Other Systems 13 2.2.4 Brief comparison of Mobile Agent Systems 13 2.3 Competing Technologies and Comparisons 15 2.4 Related Works And Their Contribution 18
CHAPTER-3 21 Mobile Agents in Wireless Internet Services 21
3.1 How Mobile Agents fit in Wireless Networks? 21 3.2 Supports for adapting Mobile Agents in Wireless Services 23 3.3 Potential Wireless Applications of Mobile Agents 27
CHAPTER-4 30 Extending NS2 to Support Simulation of Mobile Agents 30
4.1 Introduction to Network Simulator (NS2) 30 4.1.1 Software Architecture 30 4.1.2 C++ - OTcl Linkage 31 4.1.3 Major Components 33 4.1.4 Further directions 34 4.2 Why NS2? 34 4.3 Design and Implementation of Mobile Agent Model 35 4.3.1 Assumptions 35 4.3.2 Deciding the Inheritance Structure of the Model 36 4.3.3 Transferring Application-level data in NS 38 4.3.4 Design Overview 40 4.3.5 C++ and OTcl linkage for the Model 43 4.3.6 Mobile Agent Model Parameters 49 4.3.5 Mobile Agent Methods 51 4.3.6 Mobile Agent’s Event Listeners 54 4.3.7 Purpose and Functioning of MAgletInst class 55 4.3.8 Methods Implemented in class Context 56 4.3.9 Modeling of Agent’s Timer 58 4.3.10 OTcl Interface for the mobile agent model 61 4.4 Adding mobile agent model to NS package 62 4.5 Model Interactions 64 4.6 Problems encountered and their work-around 68 4.7 Validating the Mobile Agent Model 71
CHAPTER-5 78 Simulating Wireless Applications Using Mobile Agent Model 78
5.1 Information Retrieval- Scenario 1 78 5.1.1 Ideal Conditions for Mobile agent Systems with No Overhead 86 5.1.2 Effect of the Mobile Agent’s Size Overhead 88 5.1.3 Effect of Creation and Marshalling/Serialization Overhead 90 5.1.4 Effect of Number of Servers Required to Visit 92 5.2 Information Retrieval- Scenario 2 94 5.3 Mobile Agents in Middleware for Mobile Device 96
5.4 Overall Analysis of the Results 101
CHAPTER-6 105 Conclusion and Future Work 105
6.1 Conclusion 105 6.2 Future Directions 106
REFERENCES 108 APPENDIX: User’s Guide to Mobile Agent Model 113
A.1 Model Parameters Accessible Through OTcl 113 A.2 Procedures Available to User Through OTcl 115 A.3 An Example Script 119
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
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.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
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
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.
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
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.
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.
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.
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.
Remote Interactions User Remote Server Server App. Client App.
Figure 2.1. Communications using client-server paradigm.
Local Interactions User Remote Server Server App. Mobile Agent Mobile Agent
Figure 2.2. Communications using mobile agent paradigm.
In contrast to client-server paradigm, the mobile agent paradigm views computer-to-computer communication as enabling one computer not only to call procedures in another, but also to supply the procedures to be performed. Each message that the network transports consists of a procedure whose performance the sending computer either began or continued and the receiving computer is to continue and the data which are the procedure’s current state. Two computers
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
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
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
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
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
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.
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.
• 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
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.
2.4 Related Works And Their Contribution
Numerous mobile agent systems have been developed over the past decade by researchers all over the world. However, little work has been done in studying the mobile agent’s performance and very few have studied real-world wireless applications. This chapter discusses the most relevant work in the studies of overall mobile agent’s performance.
Dikaiakos and Samaras (Dikaiakos and Samaras 2000) introduced a hierarchical framework for the quantitative performance analysis of mobile agent systems. They specified this framework as a hierarchy of benchmarks, which may enable the characterization of the performance of some of the key components of the mobile agent systems. They also proposed a set of micro-benchmarks to implement the lower level of their benchmark hierarchy. Their framework has helped this work in focusing the study at the application level by using the micro-level metrics as parameters.
Strasser and Schwehm (Strasser and Schwehm 2000) proposed a mathematical model for the performance analysis of the mobile agent system using parameters derived from their Mole agent system. They used this model to study an abstract application with a single mobile agent that may visit several servers and also validated the model by using its results in a small experimental application. Their derived model has helped in identifying some of the parameters and also in validating the simulation model implemented during this study.
Jain and Anjum (Jain pg. 6) also developed an analytical model to quantify the performance benefits of using mobile agent technology and compare it to that of client-server techniques for retrieving information on behalf of a mobile user. They have studied the same example scenario as used in this thesis and is discussed in section 5.1 of chapter 5, but have not given any experimental or simulation results.
Ismail (Ismail, Hagimont, and Mossiere 1999) and developed a minimal mobile agents platform to measure the cost of the basic Java mechanisms involved in the implementation of the mobile agent platform. They compared the performance of this minimal agent system, Aglets and Java-RMI (representing the client-server paradigm) for two applications namely forward application and compress application. Their forward application is similar to the scenario 2 considered in section 5.2 of chapter 5. But they have studied it for only wired networks as the user was accessing the servers through a wired link.
The research team involved in developing the D’Agent mobile agent system at the Dartmouth College has also performed some performance analysis based on their D’Agent system. These mainly include the scalability experiments comparing the mobile agent approach to the client-server approach (Gray, Kotz, and Peterson 2001), wherein the researchers determined the maximum number of agents that can be supported by a server simultaneously under various parameters. They have also studied the performance of mobile agents in a data-filtering application where mobile client is required to filter information from a large data stream arriving across the wired network. They developed an
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.
CHAPTER-3
Mobile Agents in Wireless Internet Services
3.1 How Mobile Agents fit in Wireless Networks?
A mobile agent programmer has an option that is not available to the programmer of a traditional distributed application: to move the code to the data, rather than moving the data to the code. Moving code may be faster in many situations where the agent’s code is smaller than the data that would be moved otherwise. Or, it may be more reliable because the application is only vulnerable to network disconnection during the agent transfer, not during the interaction with the resource.
These characteristics of mobile agents make mobile agent technology especially appealing in wireless networks. On the other side traditional client-server paradigm may not be so useful to wireless networks in certain cases. The following characteristics (Chess pg. 15) of wireless devices like laptop and notebook computers, as well as portable computing devices like personal digital assistants (PDAs) and cellular phones strongly supports the use of mobile agent technology.
• They are only intermittently connected to a network, hence have only intermittent access to a server. The use of mobile agent here can be advantageous. The mobile client has the ability to create an agent request – possibly while disconnected launch the agent during a brief connection
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
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
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.
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.
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.
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
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
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.
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
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.
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.
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.
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.
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.
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
agents can execute on a given node. Here, context is responsible for creating mobile agent and also for providing each and every facility required by the agent like dispatching to other node, loading and processing the incoming agent, registering, disposing etc. It uses the existing communication facilities for mobile agent migration. Thus, a context must be implemented on top of the transport layer facilities. Just like the real world systems, NS applications are implemented on top of the transport layer agents. Any simulated application is required to implement the Application interface provided in NS. Thus the mobile agent’s context is required to implement this Application interface. Though context is implemented as an application, the mobile agent system model can be easily utilized for building real world applications on top of it.
Traffic generators Simulated applications
API API Application/ Traffic/ Exponential Agent/UDP Agent/TCP/FullTcp Application/FTP
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
applications (class Process- base class of Application), and a mechanism to pass data between applications and transport agents.
ADU is required to pack user’s data into an array that can be then included in the user data area of the packet by NS transport agents. But as said earlier, existing NS transport agents do not support user level data. Hence either user must derive new agents for sending its own data, or some type of wrapper must be used in between application and the transport layer agent. One such wrapper used is TcpApp. TcpApp is used for sending user data over TCP. It works as follows: Application (Context) send_data(ADU) process_data(ADU) send(bytes) recv(bytes) packets Application Wrapper (TcpApp) Agent (FullTcp)
Figure 4.4. Transferring user level data in NS.
Using TCP agents, all the data are delivered in sequence. Thus, a TCP connection can be seen as a FIFO pipe. Further, applications are provided with
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,
retracting agents from a remote site, disposing agent, registering agent and actual transferring of agent to another context. By registering agents, it maintains the list of currently executing agents in a hash table mapped with the agent’s ID. In order to transfer an agent’s reference, as discussed before, it needs to define an ADU (Application Data Unit) that derives from the class AppData. AppData is the base class for all ADUs. The class thus defined to carry agent’s reference is named as MobileAgentData.
Process Application Application/TcpApp Application/TcpApp/Context TclObject TclObject TimerHandler MAgent
• 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.
extends extends contains contains contains contains contains extends MAgent Context PersistencyListner MobilityListner CloneListner AppData MobileAgentData MAgentInst TcpApp
Figure 4.6. Class relationship of the model.
4.3.5 C++ and OTcl linkage for the Model
NS has special infrastructure to allow extension in both C++ and OTcl, taking into consideration the factors like efficiency provided by compiled language and easy and fast configuration capabilities provided by OTcl. Most of the code in the mobile agent model has been implemented in C++ for efficiency purposes. The part requiring less frequent access and the agent configuration is done in OTcl. Thus, we can say it is a split model between two languages. Hence, a mechanism is required to link the C++ code to that of interpreter and vice versa.
Each C++ object is required to link to the corresponding OTcl object. For example as shown in Figure 4.7 C++ Context object’s reference is linked to the class Application/TcpApp/Context object’s reference (simply a name) in OTcl. This linking is done by extending the classes like TclObject and TclClass. The C++ object whose linking with OTcl object is desired must inherit either directly or
otcl class hierarchy C++ class hierarchy -o256 context_ TclObject Application Application/TcpApp Application/TcpApp/Context Process Context Application Application/TcpApp/Context otcl Shadow Object Context C++ Object TclObject
Figure 4.7. C++ and OTcl linkage for the model.
indirectly from TclObject. Also for each such object’s class, a static class extending TclClass must be defined. This class performs two functions: (1) construct the interpreted OTcl class hierarchy to mirror the compiled class hierarchy, using the string pass to the constructor of TclClass
(“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 {
# other initializations }
Here the interpreter as part of instantiating a new Context object performs the sequence of actions. Following is a brief overview.
• First step is to obtain a reference handle for the new object from the TclObject name space, which is acting as name for the object.
• Next is to execute the above constructor for the new object. All such TclObjects are required to call their super classes in the first line as done here. This results finally in a call to TclObject constructor at the top, which is responsible for setting up the shadow object and other bindings.
• At this time the C++ create() method shown above in static ContextClass is called and instantiates the C++ object.
So this is how to bind C++ and OTcl objects. Sometimes it may also require binding different variables along with the objects; i.e. the same variable may require access from both C++ and OTcl. This can be done by establishing a bi-directional binding such that both of them
