Mobile Agents

ABSTRACT

Mobile agents, an emerging technology that makes it very much easier to design, implement, and maintain distributed systems. We will find that mobile agents reduce the network traffic, provide an effective means of overcoming network latency, and perhaps most importantly, through their ability to operate asynchronously and autonomously of the process that created them, helps us to construct more robust and fault-tolerant. Software agents are the mobile as well as the stationary ones. Mobile agents are quite a novel and powerful paradigms for representing and building distributed applications. Despite its growing popularity, the mobileagent model of computations has some disputable features and needs further study and experimentation. Java, the language that changed the Web overnight, offers some unique capabilities that are fueling the development of mobile agent systems. RTMonitor is a real-time data management system for traffic navigation applications. Here mobile vehicles initiate time-constrained navigation requests and RTMonitor calculates and communicates the best paths for the clients based on the road network and real-time traffic data.

There are four possible security attacks: Attacks from host to host, from agents to hosts, from agents to agents and finally from hosts to agents. The attacks from a malicious host on an agent can take many forms including rerouting, spying out code, spying out data, spying out control flow, manipulation of code, manipulation of data, manipulation of control flow, incorrect execution of code, masquerading and denial of execution.

College of Engg. Pandharpur

Mobile Agents

1. MOBILE OBJECTS AND MOBILE AGENTS

1.1 Software Agent:

Definition of an Agent (End-User Perspective) An agent is a program that assists people and acts on their behalf. Agents function by allowing people to delegate work to them. Agents come in myriad different types and in many settings. They can be found in computer operating systems, networks, databases, and so on.

Definition of an Agent (System Perspective) An agent is a software object that -- is situated within an execution environment; -- possesses the following mandatory properties: Reactive - senses changes in the environment and acts accordingly to those changes; Autonomous - has control over its own actions; Goal driven - is pro-active; Temporally continuous - is continuously executing;

-- and may possess any of the following orthogonal properties: Communicative - able to communicate with other agents; Mobile - can travel from one host to another; Learning - adapts in accordance with previous experience; Believable - appears believable to the end-user.

College of Engg. Pandharpur

Mobile Agents

1.2 Mobile Agent:

Mobility is an orthogonal property of agents. That is, all agents do not necessarily have to be mobile. An agent can just sit there and communicate with the surroundings by conventional means. These include various forms of remote procedure calling and messaging. We call agents that do not or cannot move stationary agents.

Definition of a Stationary Agent A stationary agent executes only on the system where it begins execution. If it needs information that is not on that system, or needs to interact with an agent on a different system, it typically uses a communication mechanism such as remote procedure calling (RPC).
In contrast, 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. 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.

Definition of a Mobile Agent

A mobile agent is not bound to the system where it begins execution. It has the unique ability to transport itself from one system in a network to another. The ability to travel, allows a mobile agent to move to a system that contains an object with which the agent wants to interact, and then to take advantage of being in the same host or network as the object.

1.3 Advantages of Mobile Agents:

They reduce the network load. Distributed systems often rely on communications protocols that involve multiple interactions to accomplish a given task. This is especially true when security measures are enabled. The result is a lot of network traffic. Mobile agents allow us to package a conversation and dispatch it to a destination host where the interactions can take place locally, see Figure 1.3.1. Mobile agents are also useful when it comes to reducing the flow of raw data in the network. When very large volumes of data are stored at remote hosts, these data should be processed in the locality of the data, rather

College of Engg. Pandharpur

Mobile Agents
that transferred over the network. The motto is simple: move the computations to the data rather than the data to the computations. They overcome network latency. Critical real-time systems such as robots in manufacturing processes need to respond to changes in their environments in real time. Controlling such systems through a factory network of a substantial size involves significant latencies. For critical real-time systems, such latencies are not acceptable. Mobile agents offer a solution, since they can be dispatched from a central controller to act locally and directly execute the controller's directions.

Fig. 1.3.1 Mobile Agents Reduce Network Load

They encapsulate protocols. When data are exchanged in a distributed system, each host owns the code that implements the protocols needed to properly code outgoing data and interpret incoming data, respectively. However, as protocols evolve to accommodate new efficiency or security requirements, it is a cumbersome if not impossible task to upgrade protocol code properly. The result is often that protocols become a legacy problem. Mobile agents, on the other hand, are able to move to remote hosts in order to establish "channels" based on proprietary protocols.

They execute asynchronously and autonomously. Often mobile devices have to rely on expensive or fragile network connections. That is, tasks that require a continuously open connection between a mobile device and a fixed network will most likely not be economically or technically feasible. Tasks can be embedded into mobile agents, which can then be dispatched into the network. After being dispatched, the mobile agents become independent of the creating process and can operate asynchronously and autonomously, see Figure 1.3.2. The mobile device can reconnect at some later time to collect the agent.

College of Engg. Pandharpur

Mobile Agents

Fig. 1.3.2 Mobile Agents Allow Disconnected Operation

They adapt dynamically. Mobile agents have the ability to sense their execution environment and react autonomously to changes. Multiple mobile agents possess the unique ability to distribute themselves among the hosts in the network in such a way as to maintain the optimal configuration for solving a particular problem.

They are naturally heterogeneous. Network computing is fundamentally heterogeneous, often from both hardware and software perspectives. As mobile agents are generally computer- and transport-layer-independent, and dependent only on their execution environment, they provide optimal conditions for seamless system integration.

They are robust and fault-tolerant. The ability of mobile agents to react dynamically to unfavorable situations and events makes it easier to build robust and fault-tolerant distributed systems. If a host is being shut down, all agents executing on that machine will be warned and given time to dispatch and continue their operation on another host in the network.

1.4 Network Computing Paradigms:

Mobile agents provide a very powerful uniform paradigm for network computing. Mobile agents can revolutionize your design and development of distributed systems. To put this claim into perspective, we will provide a brief overview and comparison of three programming paradigms for distributed computing: client-server, code-on-demand, and mobile agents

College of Engg. Pandharpur

Mobile Agents
Client-Server Paradigm. In the client-server paradigm, see Figure 1.4.1, a server advertises a set of services that provide access to some resources (e.g., databases). The code that implements these services is hosted locally by the server. We say that the server holds the know-how. Finally, it is the server itself that executes the service, and thus has the processor capability. If the client is interested in accessing some resource hosted by the server, it will simply use one or more of the services provided by the server. Note that the client needs some "intelligence" to decide which of the services it should use. The server has it all, the know-how, resources, and processor. So far, most distributed systems have been based on this paradigm. We see it supported by a wide range of technologies such as remote procedure calling, object request brokers (CORBA), and Java remote method invocation (RMI).

Fig. 1.4.1 Client-server Paradigm

Code-on-Demand Paradigm. Accordingly to the code-on-demand paradigm, see Figure 1.4.2, you first get the know-how when you need it. Say one host (A) initially is unable to execute its task due to a lack of code (know-how). Fortunately, another host (B) in the network provides the needed code. Once A receives the code, the computation is carried out in A. Host A holds the processor capability as well as the local resources. Unlike in the client-server paradigm, A does not need knowledge about the remote host, since all the necessary code will be downloaded. We say that one host (A) has the resources and processor, and another host (B) has the know-how. Java applets and servlets are excellent practical examples of this paradigm. Applets get downloaded in Web browsers and execute locally, while servlets get uploaded to remote Web servers and execute there.

College of Engg. Pandharpur

Mobile Agents

Fig. 1.4.2 Code-on-demand Paradigm

Mobile Agent Paradigm. A key characteristic of the mobile agent paradigm, see Figure 1.4.3, is that any host in the network is allowed a high degree of flexibility to possess any mixture of know-how, resources, and processors. Its processing capabilities can be combined with local resources. Know-how (in the form of mobile agents) is not tied to a single host but available throughout the network.

Fig. 1.4.3 Mobile Agent Paradigm

If we compare these three paradigms, we will see the chronological trend toward greater flexibility. The client and the server have merged and become a host. The applet and the servlet, while serving as client and server extenders, respectively, have been combined and improved with the emergence of mobile agents.

College of Engg. Pandharpur

Mobile Agents 1.5 Mobile Agent Applications

We will now take a closer look at some applications that benefit particular from the mobile agent paradigm.
Electronic commerce. Mobile agents are well suited for electronic commerce. A commercial transaction may require real-time access to remote resources such as stock quotes and perhaps even agent-to-agent negotiation. Different agents will have different goals, and will implement and exercise different strategies to accomplish these goals. We envision agents that embody the intentions of their creators, and act and negotiate on their behalf. Mobile agent technology is a very appealing solution to this kind of problem. Personal assistance. The mobile agent's ability to execute on remote hosts makes it suitable as a "assistant" capable of performing tasks in the network on behalf of its creator. The remote assistant will operate independently of its limited network connectivity, and the creator can feel free to turn his or her computer off. To schedule a meeting with several other people, a user could send a mobile agent to interact with the representative agents of each of the people invited to the meeting. The agents could negotiate and establish a meeting time. Secure brokering. An interesting application of mobile agents is in collaborations where not all the collaborators are trusted. In this case, the involved parties could let their mobile agents meet on a mutually agreed secure host, where collaboration can take place without the risk of the host taking the side of one of the visiting agents. Distributed information retrieval. Information retrieval is an often-used example of a mobile agent application. Instead of moving large amounts of data to the search engine so that it can create search indexes, you dispatch agents to remote information sources, where they locally create search indexes that can later be shipped back to the origin. Mobile agents are also able to perform extended searches that are not constrained by the hours during which the creator's computer is operational. Telecommunication networks services. Support and management of advanced telecommunication services are characterized by dynamic network reconfiguration and user customization. The physical size of these networks and the strict requirements under which they operate call for mobile agent technology to form the "glue" that keeps such systems flexible yet effective. Workflow applications and groupware. It is in the nature of workflow to support the flow of information between co-workers. The mobile agent is particular useful here since, in

College of Engg. Pandharpur

Mobile Agents
addition to mobility, it provides a degree of autonomy to the workflow item. Individual workflow items fully embody the information and behavior needed for them to move through the organization independent of any particular application. Monitoring and notification. This is one of the "classical" mobile agent applications that highlight the asynchronous nature of mobile agents. An agent is able to monitor a given information source without being dependent on the location from which it originates. Agents can be dispatched to wait for certain kinds of information to become available. It is often important that monitoring agents have life spans that exceed or are independent of the computing processes that create them. Information dissemination. Mobile agents embody the so-called Internet "push" model. Agents are able to disseminate information such as news and automatic software updates for vendors. The agents will bring the new software components as well as the installation procedures directly to the customer's personal computer and will autonomously update and manage the software on the computer. Parallel processing. Given that mobile agents can create a cascade of clones in the network, one potential use of mobile agent technology is to administer parallel processing tasks. If a computation requires so much processor power as to that it must be distributed among multiple processors, an infrastructure of mobile agent hosts could be a plausible way to get the processes out there.

1.6 Contemporary Mobile Agent Systems

Java has generated a flood of experimental mobile agent systems. Numerous systems are currently under development, and most of them are available for evaluation on the Web.

We will, however, mention a few interesting Java-based mobile agent systems: Aglets, Odyssey, Concordia, and Voyager.
Aglets. This system mirrors the applet model in Java. The goal was to bring the flavor of mobility to the applet. The term aglet is indeed a portmanteau word combining agent and applet. We attempted to make Aglets an exercise in "clean design," and it is our hope that applet programmers will appreciate the many ways in which the aglet model reflects the applet model. Odyssey. General Magic Inc. invented the mobile agent and created the first commercial mobile agent system called Telescript. Being based on a proprietary language and network architecture, Telescript had a short life. In response to the popularity of the

College of Engg. Pandharpur

Mobile Agents
Internet and later the steamrollering success of the Java language, General Magic decided to re-implement the mobile agent paradigm in its Java-based Odyssey. This system effectively implements the Telescript concepts in the shape of Java classes. The result is a Java class library that enables developers to create their own mobile agent applications. Concordia. Mitsubishis Concordia is a framework for the development and management of mobile agent applications, which extend to any system supporting Java. Concordia consists of multiple components, all written in Java, which are combined together to provide a complete environment for distributed applications. A Concordia system, at its simplest, is made up of a standard Java VM, a Server, and a set of agents. Voyager. ObjectSpace's Voyager is a platform for agent-enhanced distributed computing in Java. While Voyager provides an extensive set of object messaging capabilities it also allows object to move as agents in the network. We can say that Voyager combines the properties of a Java-based object request broker with those of a mobile agent system. In this way Voyager allows Java programmers to create network applications using both traditional and agent-enhanced distributed programming techniques. We would like to note that the Java-based mobile agent systems have a lot in common. Beside the programming language they all rely on standard versions of the Java virtual machine and Javas object serialization mechanism. Common server based architecture permeates all the systems. Agent transport mechanisms and the support for interaction (messaging) vary a lot. Although a majority of the contemporary mobile agent systems are based on the Java language system, we will also be able to find other languages in use. Most significant languages are Tcl and Python. Agent Tcl. This is a mobile agent system whose agents can be written in Tcl. Dartmouth Colleges Agent Tcl has extensive navigation and communication services, security mechanisms, and debugging and tracking tools. The main component of Agent Tcl is a server that runs on each machine and that allows the entire execution state including local variables and instruction pointer to move. When an agent wants to migrate to a new machine, it calls a single function, agent jump, which automatically captures the complete state of the agent and sends this state information to the server on the destination machine. The destination server starts up a Tcl execution, loads the state information into this execution environment, and restarts the agent from the exact point at which it left off. Ara. Tcl-based Ara from University of Kaiserslautern is a platform for the portable and secure execution of mobile agents in heterogeneous networks. The research project is

10

College of Engg. Pandharpur

Mobile Agents
primarily concerned with system support for general mobile agents regarding secure and portable execution, and much less with application-level features of agents, such as agent cooperation patterns, intelligent behavior, and user modeling. Tacoma. The TACOMA project focuses on operating system support for agents and how agents can be used to solve problems traditionally addressed by operating systems. The TACOMA system is based on UNIX and TCP. The system supports agents written in C, Tcl/Tk, Perl, Python, and Scheme (Elk). The system itself is implemented in C.

1.7 Comparison:
11

College of Engg. Pandharpur

Mobile Agents

From the previous section, it is apparent that there are differences among the various systems. The table below highlights the pros/cons of each system.

12

College of Engg. Pandharpur

Mobile Agents

2. MOBILE AGENT STANDARDIZATION: MASIF

Clearly, the contemporary mobile agent systems differ widely in architecture and implementation, thereby impeding interoperability and rapid deployment of mobile agent technology in the marketplace. To promote interoperability, some aspects of mobile agent technology must be standardized. The companies Crystaliz, General Magic Inc., GMD Fokus, IBM Corporation, and the Open Group have jointly developed a proposal for a Mobile Agent System Interoperability Facility (MASIF) and brought it to the attention of the Object Management Group (OMG). MASIF addresses the interfaces between agent systems, not between agent applications and agent systems. Even though the former seems to be more relevant for application developers, it is the latter that allows mobile agents to travel across multiple hosts in an open environment. MASIF is clearly not about language interoperability. Language interoperability for mobile objects is very difficult and MASIF is limited to interoperability between agent systems written in the same language, but potentially by different vendors. Furthermore, MASIF does not attempt to standardize local agent operations such as agent interpretation, serialization, or execution. We can that say MASIF defines the interfaces at the agent system level rather than at the agent level.

2.1 MASIF standardization Areas:

Agent Management. There is interest in the mobile agent community to standardize agent management. It is clearly desirable that a system administrator who manages agent systems of different types can use the same standard operations. It should be possible to create an agent given a class name for the agent, suspend an agents execution, resume its execution, or terminate it in a standard way. Agent Transfer. It is desirable that agent applications can spawn agents that can freely move among agent systems of different types, resulting in a common infrastructure. Agent and Agent System Names. In addition to standardizing operations for interoperability between agent systems, the syntax and semantics of various parameters must be standardized too. Specifically, agent name, and agent system name should be

13

College of Engg. Pandharpur

Mobile Agents
standardized. This allows agent systems and agents to identify each other, as well as applications to identify agents and agent systems. Agent System Type and Location Syntax. The location syntax must be standardized so that an agent can access agent system type information from a desired destination agent system. The agent transfer can only happen if the destination agent system type can support the agent. Location syntax also needs to be standardized so that agent systems can locate each other.

Fig. 2.1.1 MASIF region concept.

14

College of Engg. Pandharpur

Mobile Agents

Fig. 2.1.2 MASIF agent system with places, agents and communication infrastructure

3.BUILDING DISTRIBUTED APPLICATIONS WITH JAVA MOBILE AGENTS

3.1 Mobile agents as a model of distributed computations:

Mobile agents are an active and exciting area of research. The computational model, based on mobility, can be viewed as a replacement, refinement or extension of the traditional client/server paradigm. The mobile agent framework emerged in the pursuit of open and decentralized models, relevant to the dynamic and distributed nature of computations on the Internet.
In the context of this framework, an application can be designed and implemented as a collection of mobile agents. A mobile agent is typically defined as an autonomous program, which can migrate during its execution from one host to another in a heterogeneous network. A mobile agent has several key features: Autonomy: A mobile agent is a separate computational unit, with its own thread of execution, independent of other units;

15

College of Engg. Pandharpur

Mobile Agents
Migration: It can suspend its execution at the hosting machine, transfer its current state (data) and code to a different host and resume its execution there; Communication: A mobile agent can communicate with other agents on the local host or remote machines. Mobility itself is a disputable technology for organizing distributed computations. Suppose, agent X resides on host A, while resource Y is located on host B Fig. 3.1.1. One possible scenario for X to access the remote resource follows the traditional request/response style. Alternatively, the agent could move to the location of the resource and interact with it locally.

Fig. 3.1.1 Remote vs. local agent-resource interaction

The basic motivation behind agent migration is to perform access and information processing locally to a resource or the user, instead of remotely. On the other hand, mobility raises security and efficiency issues. In the computational model with mobile agents, the distinctions between clients and Servers get blurred. Agents inherently interact as peers, but they can integrate flexibly into the client/server framework. An agent can act as a client or a server, depending on the specific application. Both client and server agents can change locations according to the available network resources. In a typical scenario, an agent starts on the client side, moves to the server that provides resources, performs operations on the server side (e.g., information retrieval and filtering) and then returns the final results to the client side. The model with mobile agents has numerous attractive aspects, including:

16

College of Engg. Pandharpur

Mobile Agents
Potentials for reducing network traffic: By performing time and traffic consuming operations locally on the server, mobile agents can reduce bandwidth consumption, especially if there is no need to transmit intermediate data and the network is lowbandwidth. On the other hand, the very process of migration consumes computing and network resources. The choice between migration and remote interaction (e.g., via RPC (Remote Procedure Call) or message-passing) should be based on the current network and computational conditions; Disconnected operation: A mobile agent is not tightly attached to its dispatching host; it can continue functioning even if its "home" is unavailable or unreachable, and send back results upon reconnection. This feature is particularly useful for portable computing devices; "On-the-fly" deployment of software components: Software components can be flexibly and dynamically deployed in the form or using mobile agents. This facilitates the rapid prototyping of distributed applications. Computations in the mobile-agent model are essentially organized in a "jump-act jump pattern. This pattern is particularly suitable for developing information retrieval and network management applications. But there are still diverse open problems to be faced, like reducing migration and communication overheads, implementing secure migration, protecting both hosts and agents, and imposing limits on agents' resource consumption. The mobile-agent model is a very general framework for expressing and developing distributed applications. Its higher level of abstraction hides communication details from the developer and makes it easier to comprehend and use, compared to lower-level models, based on message-passing, RPC or some combination of traditional approaches. This is especially important for building distributed applications, which usually consist of numerous, interacting components.

3.2 Java mobile Agents:

A mobile-agent system is a distributed execution environment for mobile agents. Existing mobile systems are numerous and diverse. Their conceptual model is shown in Fig.3.2.1,

17

College of Engg. Pandharpur

Mobile Agents

Fig. 3.2.1 A mobile-agent system

An agent is executed as a process or a thread in the context of the agent runtime environment (agent server). This engine must run at each network site willing to accept visiting agents. It provides the following basic functionality: execute agents, apply security mechanisms to authenticate agents and control access to local resources send and receive mobile agents via the communication infrastructure and mediate inter-agent communication. Mobile-agent platforms differ in many aspects. They can be roughly divided into Java- and non-Java-based, using languages like C/C++ and various scripting languages (e.g., Tcl/Tk). Some platforms interpret agent programs directly, while others interpret intermediate code (byte code), possibly using "on-the-fly" compilation. Two basic migration mechanisms are supported: "strong" and "weak" migration. A system with "strong" migration (e.g., Dartmouth College Agent Tcl) provides a primitive language construct (jump), which captures the complete agent's state and after the migration execution is resumed from the point of the jump. Java-based systems cannot support "strong" migration without modifications to the standard JVM (Java Virtual Machine). They provide "weak" mobility: agent execution is resumed at some known entry point, not at the point of interruption. Java is the most widely used language tool in mobile-agent systems for a number of reasons, including: Portability: The virtual machine model of Java facilitates programs portability and efficiency. Java programs are compiled into byte code for a virtual stack-based machine; Security: Java has built-in security mechanisms (security managers, security policies); Threads support: Java mobile agents are special Java objects, executed as threads within the agent runtime environment;

18

College of Engg. Pandharpur

Mobile Agents
Support for migration and communication: The serialization, dynamic class loading and remote method invocation (RMI), built in Java, are directly used to implement migration and communication in mobile-agent platforms.

The conceptual model of a Java-based mobile-agent platform is depicted in Fig. 3.2.2. The agent platform provides an agent API with the basic functionality for agent management, migration and communication, in the form of Java packages. TCP/IP is used as the main transport mechanism. The agent server is multi-threaded and runs on top of the JVM.

Fig. 3.2.2 Java-based mobile-agent system

Two of the most popular Java-based platforms are IBM Aglets and IKV++ Grasshopper. IBM Aglets is one of the first Java-based mobile-agent platforms. Aglets are Java objects augmented with migration and communication capabilities. The platform supports diverse agent interactions using messages, byte streams and RMI. The Grasshopper platform is quite new and attractive, providing rich functionality and elaborate security mechanisms. It has ports for Windows 9x/NT/2000 and UNIX (Linux, Solaris) systems. Its distributed processing environment is structured into regions (optional), agencies and places. Regions provide naming services and facilitate the management of distributed components. Grasshopper agents can be mobile or stationary. They "live" in places, within agencies. An agency accommodates at least one, default place. Each host, willing to accept and execute agents, should run at least one agency. The agency is the runtime environment for mobile and stationary agents. The general structure of an agency is illustrated in Fig .3.2.3,

19

College of Engg. Pandharpur

Mobile Agents

Fig. 3.2.3 Structure and services of a Grasshopper agency

A place is a container of agents, grouped according to their functions. Each agency provides the following services:
Communication: Supports the remote interaction between Grasshopper components, based on CORBA IIOP, RMI and plain sockets. RMI and sockets can be SSL-secured. Communication can be synchronous or asynchronous, unicast or multicast; Registration: Provides information about Grasshopper components; Management: Monitors and controls agents and places; Transport: Supports agents migration from one agency to another; Security: Performs agent authentication and enforces access control policies; Persistence: Responsible for saving agents and places to secondary storage.

The Grasshopper platform is open and configurable. Some of the core services are optional (e.g., persistence), additional communication protocols and security mechanisms can be integrated (e.g., SSL is an add-on package).
The Grasshopper agent API includes basic primitives for agent creation and initialization, operation, destruction, migration and inter-agent communication. Destruction and migration could be initiated by the agent itself or by another component.

20

College of Engg. Pandharpur

Mobile Agents
Grasshopper mobile agents are instances of classes extending the basic API Mobile Agent class. Agent's behavior is specified in its live() method. When creating an agent, the runtime environment generates and assigns to it a unique identifier. To be able to migrate or communicate, an agent needs to specify the target address. Grasshopper addresses are URL-like notations of the following general form: <protocol>://<host>:<port>/<agency>/<place>. The <port> and <place> fields are optional. The host is specified by its name or IP

Address.
Migration in Grasshopper is based on the Java serialization and deserialization facility. It involves a sequence of several basic steps, performed transparently for the agent programmer: The agent, willing to migrate, is stopped; Its current data state (non-transient instance variables) is serialized, i.e. "flattened", into a byte stream; The bytestream representation, together with some additional information (class name and codebase), is transmitted to the remote target host; The target agency creates a new instance of the agent with its reconstructed (deserialized) state.

Basically, migration is reduced to creating a new agent at the target location and destroying the "original" agent.
The serialization facility built in Java cannot capture the execution state of a thread, and hence migration is "weak" - after migration, execution is restarted at some entry point (method). One possible solution of the problem is to modify the JVM, which is hardly acceptable, as it limits the mobile-agent platform portability. If needed, "strong" migration could be simulated by means of separating different execution paths, depending on the agent's data state.

21

College of Engg. Pandharpur

Mobile Agents 3.3 Monitoring server activity with mobile agents:

Mobile agents are quite a new and developing technology. By experimenting with mobileagent applications, we can explore the potentials of the general model and its particular implementations and identify the limitations imposed by them. Monitoring the activity of network servers is conventionally implemented with tools, located at the server site. But this task is essentially a distributed computing problem: data originates in one location; it is processed at the source or in a different location, while its presentation could be someplace else. To solve the task, we build a sample-distributed application as a collection of simple mobile agents. The application functionality is influenced by using Grasshopper v.2.2.

The monitoring application is composed of three basic types of agents:

Information agents reside on the monitored server side, processing and filtering raw data; Display agents reside close to the end-user, receiving processed data from information agents and visualizing it relevantly; Master agent manages and controls the collection of information and display agents and provides the basic user interface of the application. There are two information agents: a file watcher and a search agent. The watcher agent checks the size of the server log file at user-specified intervals. File growth information is used as an indirect measure of server activity. A display agent is plotting a graph of file growth per unit time, dynamically shifting the time "window". Another pair of Information/display agents search the log file for user-specified text and output the results. This technique can be used to keep track of an arbitrary network service, maintaining a log file (e.g., a Web server). The monitoring application combines agent migration and remote communication, using plain sockets. Various scenarios for organizing agent interactions can be designed. One difference between them is who initiates communication - the information or display agents. Fig.3.3.1 shows one possible scenario, with display agents as communication initiators. The arrows reflect the interactions between agents. Information agents act as server agents (provide data), while display agents are clients (consume data) and hence initiate data requests.

22

College of Engg. Pandharpur

Mobile Agents

Fig.3.3.1 The monitoring agent system

All agents in the application are mobile. Information agents move to the location of

the respective server hosts, while the master and display agents could share the same local host. The master agent creates, places, configures and controls the collection of "slave" agents. The user can specify the locations of the servers to be monitored, the interval between file growth checks and the texts to be searched. The GUI functionality of display agents is organized as a separate thread. The following master agent fragment illustrates the migration of "slave" agents, initiated by the master:

try { getAgentSystem().moveAgent(id, new GrasshopperAddress(location)); } catch (Exception e) { log("Migration failed: ", e); }

The methods getAgentSystem(), moveAgent() and log() are all Grasshopper API methods. The getAgentSystem() method provides the interface to the local agency functionality, and log() displays a text message.

23

College of Engg. Pandharpur

Mobile Agents
One of the key design decisions is how to organize inter-agent communication. Some of the communication links are unidirectional (master agent control functions), while the communication between information and display agent is bi-directional: display agents request and receive data from information agents. Grasshopper communication service provides synchronous and asynchronous communication, both based on remote method invocation. Asynchronous results can be acquired by means of blocking, polling or notification. To implement a most flexible communication pattern, we prefer asynchronous communication with notification. In the context of RMI, two communicating parties are distinguished: server and client. Information agents provide public methods to be invoked remotely, hence they act as remote servers, and while display agents are the clients. The client cannot directly access a server. The publicly accessible server methods are specified as a remote server interface, implemented by the server class. The client generates and accesses a local server proxy object as an instance of the remote server interface, not the server class itself. The proxy performs the actual communication with the remote server, transparently for the developer. Notification allows the client to get notified about available results, without blocking. The server interface of the file watcher agent includes a getResult() method, which returns the growth of the log file (fPath) per unit time:

public interface IFileWatcher { public long getResult(String fPath); ... } The next fragment illustrates the basic operation of the graph display agent: Listener listener = new Listener(); ... while (true) { try { serverProxy.getResult(fPath);

24

College of Engg. Pandharpur

Mobile Agents
} catch (Exception e) {...}

FutureResult futureResult = ((IFutureResult)serverProxy).

getFutureResult(); futureResult.addResultListener(listener); ... // repaint try { sleep(interval); } catch (InterruptedException e) {...} } // while

The display agent periodically calls the getResult() method of the information server proxy. To be able to receive results, it constructs a FutureResult object which buffers asynchronous replies. To enable notification, the display agent also creates a listener object (an instance of its inner Listener class) and attaches it to the FutureResult object. Thus, the listener's resultHasArrived() method is automatically called upon receiving data from the server.

3.4 Agent Characteristics of Java :

Java is an object oriented network sawy programming language. Let us view some of the properties of Java that make it a good language for mobile agent programming.

Platform-Independence. Java is designed to operate in heterogeneous networks. To enable a java application to execute anywhere on the network, the compiler generates architecture-neutral byte code, as opposed to non-portable native code. For this code to be executed on a given computer, the Java runtime system needs to be present. There is

25

College of Engg. Pandharpur

Mobile Agents
no platform - independent aspects of the Java language. Primitive data types are rigorously specified and not dependent on the underlying processor or operating system. Even libraries are platform independent parts of the system. For example, the window library provides a single interface for the GUI that is independent of the underlying operating system. It allows us to create a mobile agent without knowing the types of computers it is going to run on. Secure execution. Java is intended for use on the Internet and intranets. The demand for security has influenced the design in several ways. For example, Java has a pointer model that eliminates the possibility of overwriting memory and corrupting data. Java simply does not allow illegal type casting or any pointer arithmetic. Programs are no longer able to forge access to private data in objects that they do not have access to. This prevents most activities of viruses. Even if someone tampers with the byte code, the Java runtime system ensures that the code will not be able to violate the basic semantics of Java. The security architecture of Java makes it reasonably safe to host or access private information. Dynamic class loading. This mechanism allows the virtual machine to load and define classes at runtime. It provides a protective name space for each agent, thus allowing agents to execute independently and safely from each other. The class-loading mechanism in extensible and enables classes to be loaded via the network. Multithread programming. Agents are by definition autonomous. That is, an agent executes independently of other agents residing within the same place. Allowing each agent to execute in its own lightweight process, also called a thread of execution, is a way of enabling agents to behave autonomously. Fortunately, Java not only allows multithread programming but also supports a set of synchronization primitives that are built into the language. These primitives enable agent interaction. Object serialization. A key feature of mobile agents is that they can be serialized and deserialized. Java conveniently provides a built-in serialization mechanism that can represent the state of an object in a serialized form sufficiently detailed for the object to be reconstructed later. The serialized form of the object must be able to identify the java class from which the objects state was saved, and to restore the state in a new instance. Objects often refer to other objects. Those other objects must be stored and retrieved at the same time, to maintain the object structure. When an object is stored, all the objects in the graph that are reachable from that object are stored as well.

26

College of Engg. Pandharpur

Mobile Agents
Reflection. Java code can discover information about the fields, methods, and

constructors of loaded classes, and can use reflected fields, methods and constructors to operate on their underlying counterparts in object, all within the security restrictions. Reflection accommodates the need for agents to be smart about themselves and other agents.

Although the Java language system is highly suitable for creating mobile agents, we should be aware of some significant shortcomings. Inadequate support for resource control. The Java language system provides no means for us to control the resources consumed by a Java object. For example, an agent can start looping and waste processor cycles. The agent can also start consuming memory resources. These two examples relate to a specific type of security attack termed denial of service. This is the most feared type of attack by mobile agents. Agents swarm into a computer and take over all its resources, making it impossible for the owner to control his or her own computer. Unfortunately, Java provides no ways for the host to limit the processor and memory resources allocated by a given object or thread. A related issue is the ability of the agent to allocate resources external to the program, for example by opening files and sockets, and creating windows. The agents allocation of these resources can be controlled but once the agent is disposed of or dispatched to another host, these resources must be released. However, it is difficult to do so, because there is no way of binding such resources to a specific object. So what we may see is a mobile agent that forgets its GUI and leaves behind an open window on our display when it leaves for another host. No protection of references. A Java objects public methods are available to any other object that has a reference to it. Since there is no concept of a protected reference, some objects are allowed access to a larger set of public methods in the Java objects interface than others. This is important for the agent. There is no way that it directly can monitor and control which other agents are accessing its methods. We have found that a practical and powerful solution to this problem is to insert a proxy object between the caller and the callee to control access. This not only provides protection of references. It also offers a solution to the problem mentioned in the next item and provides location transparency. No object ownership of references. No one owns the references to a given object in

Java. For an agent, this means that we can take its thread of execution away from it, but

27

College of Engg. Pandharpur

Mobile Agents
we cannot explicitly void the agent (object) itself. This is a task for the automated garbage collector. At present, the garbage collector will not reclaim any object until all references to the object have been voided. So if some other agent has a reference to our agent, it will unavoidably open a loophole for that agent to keep our agent alive against our will. All we can do is to repeat the warning against giving away direct references to agents in Java. The upcoming Java Development Kit (JDK) 1.2 provides support for weak reference, which will solve this problem. No support for preservation and resumption of the execution state. It is currently impossible in Java to retrieve the full execution state of an object. Information such as the status of the program counter and frame stack is permanently forbidden territory for Java programs. Therefore, for a mobile agent to properly resume a computation on a remote host, it must rely on internal attribute values and external events to direct it. An embedded automation can keep track of the agents travels and ensure that computations are property halted and properly resumed.

4. A FRAMEWORK FOR NETWORK MANAGEMENT USING MOBILE AGENTS

4.1 Introduction:
Network management essentially involves monitoring and controlling the devices connected in a network by collecting and analyzing data from the devices. Due to the increasing use of heterogeneous computing environments, network management becomes more and more difficult. Users increasing expectations for reliability and quality of service make it even harder.

28

College of Engg. Pandharpur

Mobile Agents
Conventional network management is based on SNMP (Simple Network Management Protocol) for large networks. It gives network administrators the flexibility of managing the whole network from a single place. SNMP is often used in centralized network management environments. Its drawbacks include information bottleneck at the manager, lack of scalability, excessive processing load at manager, and heavy usage of network bandwidth by network management actions, management intelligence too centralized.
An alternative is distributed network management, in which the centralized management strategy is replaced by interoperable management systems. Distributed management solves the problems with centralized management to some extent. However, it still has some drawbacks like limited scalability and complex coordination mechanisms between management stations. The latest trend is to deploy mobile agents to manage todays large heterogeneous networks. Mobile agents are special software objects that are autonomous and have the ability to migrate from one node to another node, carrying logic and data, performing actions on behalf of the user. Mobile agent based network management is to equip agents with network management capabilities and allow them to issue requests to managed devices (or nodes) after migrating to these nodes. Mobile agent based network management has many advantages; these are performance, configuration, accounting, and fault management. Performance management involves gathering statistics about network traffic and schemes to condense and present data. Measuring performance of networks using centralized SNMP based management is very difficult due to reasons like network delays and information bottleneck at the central management station. The solution to performance management using mobile agents is superior to conventional management techniques. Mobile agents give the flexibility of analyzing the managed node locally.

Instead of querying the managed node for every fixed interval and analyzing the performance from management station, MA can be dispatched to analyze the node locally.
Advantages with mobile agent based performance monitoring include: Information collected using this approach is more accurate since no delays are involved. Local manipulation of data on the node. Filtering operations could be performed on managed node. This condenses and organizes data before it brings the analysis back to the network management station.

29

College of Engg. Pandharpur

Mobile Agents
Configuration management is concerned with initializing a network, service provisioning, and adding and updating relationships among components and status of components during operation. Mobile agents can help smoothen configuration management which otherwise is a complex process. Configuring a device, which is connected in a network, requires setting a number of parameters and installing software components. Currently the manager has to perform all the tasks manually. A mobile agent could be equipped with the necessary parameters and software and dispatched to the agent that needs attention regarding configuration. This approach is more efficient in the sense that it helps in disconnected operation between management station and managed node. Accounting management is the process of gathering statistics about the resources of on the network, establishing metrics, checking quotas and determining costs. The same strategies, as described above, could be used for achieving proper accounting management. Fault monitoring involves identifying faults in devices connected to a network. Detection of faults can be achieved through the use of mobile agents. A mobile agent performing analysis of devices connected in a network could be programmed to have the ability to report to the management station about all nodes whose utilization increases a certain threshold. In some cases we need to rely on low-level protocols for detection and correction of fault. Since our flexible architecture doesnt loose the advantage of conventional SNMP management techniques, low-level fault detecting schemes based on SNMP could be used in the detection and correction of some faults.

To take advantage of mobile agents for network management, Mobile Agent based Network Management (MAN) forms a layer over conventional SNMP based management. This ensures that the advantages of SNMP are not lost and also serves the purpose of managing legacy SNMP based systems. Mobile agents and SNMP based management should coexist in building an efficient management system. While mobile agent technology has long been pursued, its applications in network management are still rudimentary.

4.2 MAN: A New Network Management Framework:

SNMP is the dominant protocol for network management. SNMP supports the operations: Get-Request; Get Next-Request Get-Response, Set-Request, Trap. In SNMP a management application uses the manager protocol to communicate with the managed system, which uses the agent protocol to communicate with the MIB and the manager protocol. This model is often used

30

College of Engg. Pandharpur

Mobile Agents
to manage whole network from a central management station. Processing of managed data is done at the management station. Network management stations interact with SNMP agents in managed nodes. Each SNMP agent is essentially a daemon process that responds to requests from management stations. SNMP agents are organized in different ways in different platforms. MAN framework is a hybrid model, which has features of mobile agents as well as SNMP. MAN gives the manager the flexibility of using SNMP model or mobile agent based management depending on the management activity that is involved. This architecture has many advantages over the existing architectures. Architecture and Components

Fig.4.2.1 shows the MAN architecture for network management using mobile agents. The manager is given the flexibility of deciding whether to use SNMP or mobile agents.

Fig. 4.2.1 Architecture of MAN In this approach the MAN station assumes responsibilities of a client. All managed nodes are servers, which have mobile agent execution environment and respond to SNMP queries from mobile agents when they visit the servers and manipulate data locally. When the client in the MAN needs access to data on a network-connected device, it does not talk directly to the server over the network. Instead, the client actually dispatches a mobile agent to the servers machine. Once on the servers machine, the MA makes its requests to the server directly. When the entire transaction is complete, the mobile agent returns to the management station with the results. The MAN provides Java-compliant interfaces to network management services. The MAN itself was developed in Java as well because of Javas write-once run- everywhere commitment

31

College of Engg. Pandharpur

Mobile Agents
and its dynamic class loading and object serialization features. The MAN framework consists of the following major components:

Management Application.- The management application has a Graphical User Interface (GUI), which coordinates with the agent applications underneath it. It interacts with Mobile Agent Producer (MAP) in configuring a MA with details such as the parameters to be evaluated at the managed nodes site and health functions. Mobile Agent Execution Environment (MAEE). MAEE is an execution environment for the execution of MAs. MAEE could be characterized as home for mobile
agents from where they could execute their duties. The agent comes to the managed node from the management station, executes its management task and goes back to the management station. Here Aglet Server is MAEE. Aglet server is the mobile agent execution environment in machines that host mobile agents. In MAN, MAEE acts as an interface between MAs and SNMP agent at the managed node. Mobile Agent Producer (MAP) MAP could be characterized as a tool for generating customized MAs that are equipped according to the requirements of network manager. By using MAP the functional characteristics of MAs, which roam in the network to collect information from managed nodes, can be changed dynamically (i.e. at runtime). Dynamic creation and configuration of MAs is achieved using MAP. Mobile Agents (MA) A typical mobile agent is Autonomous, Mobile, Persistent, Communicative/ collaborative, Active /proactive. The ability to travel allows mobile agents to move to the network element, which is to be managed. In other words, mobility of MAs could be exploited to transfer the MA to managed node and interact locally with the SNMP agent on the managed node.

In MAN framework mobile agents are provided with: The list of nodes to be managed. SNMP statistics of interest. Health functions defined by the user.

Aglets as the agent development environment. Aglets Software Developer Kit (ASDK) provides a modular structure, easy-to-use API for programming of mobile agents and excellent documentation.

32

College of Engg. Pandharpur

Mobile Agents

4.3 MAN over TCP/IP:

The architecture of MAN demonstrates mobile agents as software entities that roam in the network over TCP/IP. The operation of MAN over TCP/IP suggests a healthy advantage of Mobile Agent based management. Using conventional management techniques, retrieving large amounts of MIB data involves a high number of Protocol Data Unit (PDU) exchanges over network. To improve the above solution RFC1187 describes an algorithm that speeds up the retrieval of an entire table in a MIB by using multiple threads in parallel, where each thread retrieves a portion of table. But this algorithm achieves reduced latency at the cost of the following disadvantages: To make above algorithm work a manager which supports multiple threads and which has knowledge of distribution of instance identifiers in MIB is required. Situation could get worse in case packets get dropped with in network. Multiple threads cause bursty SNMP traffic on the managed node. Another operation, Get-bulk operation could be used to perform bulk retrieval of MIB data, but still Get-bulk operation has to fit into a single UDP packet, since SNMP works over UDP. For grouping large amounts of MIB data which might be in the order of hundreds of kilobytes, results in large overall delay because UDP packets can handle packets of size less than or equal to 64 kilobytes.

The state carrying and state restoring capability of mobile agents could be exploited to carry management data. Mobile agents can be configured to procure data from different tables of MIB, which is selective retrieval of MIB parameters, where as Get-next and Getbulk operations are supported over well-related subsets of data in MIB. For example Getnext can be used only to get the next row of the current interaction with MIB table. If management involves large amounts of data and multiple machines MAN reduces end-toend latency. Philippe and Sprinkles mentioned the advantage of adding SNMP over TCP/IP in Bulk transfers of MIB data. They mentioned that the effect of moving from UDP to TCP removes the limitation of maximum SNMP message size of 64 kilobytes. Mobile agents, which work over TCP/IP, could be used for network management. MAN suggests an architecture in which mobile agent based management forms as a layer over conventional SNMP based management. This also ensures that advantages of SNMP based management 33

College of Engg. Pandharpur

Mobile Agents
are not lost. So the Network Manager can be given the flexibility of selecting UDP or TCP based on the amount of management data that is involved. When a manager needs small amount data from a small set of managed nodes, UDP is a better choice. When a large amount of MIB data is to be retrieved from multiple managed nodes mobile agent based management is desirable.

Fig. 4.3.1 MAN over TCP and UDP

5. CONTROL MECHANISMS FOR MOBILE AGENTS

We define control mechanisms for mobile agents as mechanisms that provide at least one of the following functionalities: Locating agents. A mechanism for locating agents returns either the current location of the agent, or the information that the agent does not exist anymore. In many applications the

34

College of Engg. Pandharpur

Mobile Agents
ability to get information about the computation in progress, i.e. to get status information from the working agents, or to interact with the agents, e.g. to change their behavior, is essential. To do this reliably and with acceptable costs, mechanisms have to be used that locate the agent in order to communicate. To interact with an agent, in principle an alternative to explicitly locate the agent exists. By employing an anonymous group communication mechanism the agent would not have to be located. Examples for anonymous group communication mechanisms are distributed tuple spaces or distributed event channels as defined by the OMG. But these mechanisms either provide only best-effort semantics, or are extremely expensive if reliable communication is needed. Detection of orphan agents. A mechanism that provides orphan detection functionality decides whether an agent is an orphan or not. By employing such a mechanism a mobile agent system can remove orphan agents, thus reclaiming occupied resources. In a commercial environment, or in an environment with limited resources, it is important that only as many resources as needed are used. Consider the following scenario: an agent A on a place P creates child agents that search for prices of VCRs in a distributed database and report the results back to agent A. Place P crashes and the agent A is lost. The child agents are no longer able to report their findings, and unnecessarily consume resources. By detecting that the child agents are orphans the system can remove them and thus minimize the resource consumption. Termination of agents. A mechanism providing this functionality allows an agent to be stopped and removed from the system, regardless of the agents location. For example, if the results of a mobile agent searching a distributed database are no longer relevant, or if an agent monitoring an information source is no longer needed, then the agent could be terminated. One possibility to implement a mechanism for terminating agents is to use a mechanism to locate the agent and to send the termination command to it subsequently.

6. SECURITY IN MOBILE AGENT SYSTEMS

There are four possible security attacks: Attacks from host to host, from agents to hosts, from agents to agents and finally from hosts to agents. The attacks from a malicious host on an agent can take many forms including rerouting, spying out code, spying out

35

College of Engg. Pandharpur

Mobile Agents
data, spying out control flow, manipulation of code, manipulation of data, manipulation of control flow, incorrect execution of code, masquerading and denial of execution.

6.1 Possible Host Attacks Against Mobile Agents:

There are several possible host attacks that threaten the security of an agent. These attacks include: The host holds the agent longer than necessary which harms a time-critical agent, charges the agent extra money, or modifies the agents code or state which causes the agent to perform some work on behalf of the malicious host. Rerouting the agent to a different destination machine. Or preventing the agent from migrating at all. Most of the hosts see all of the code of the agent as they execute it. And it might happen that the code can be seen even before the execution time. Also, if the agents code was constructed using standard building blocks and libraries in order to reduce code migration cost, the details of these blocks will be available for the host. This knowledge of code allows the host to know more about the execution strategy of the agent, the exact physical structure of code and data in the hosts memory and may be the knowledge of the agents data. When this threat takes place, it does not leave any trace or indication of whether the host has read the data or not. This is very critical for agents carrying secret data that requires extreme privacy. The next execution step in the agents code can be simply recognized by the host if it knows the entire code of the agent and its data. And even if the data was protected, the control flow cannot be fully protected. And thus, the host can easily deduce more information about the state of the agent. If the host can read the code and access the agents code memory, it would be easy for it to modify the agents program. This modification may be by inserting any virus, which last permanently, or by altering the behavior of the agent. Permanent code manipulation is impossible if one can cryptographically sign the code of the agent. If the code does not change over the execution time, this will be great since the owner can sign the agent at start time. If the owner managed to protect the code so that the host does not know what each line of code does exactly and where this line is stored, code manipulation attacks would be impossible. When the host knows the physical location of data in the memory it can modify it specially if it knew the semantics of the data elements. But if these data elements are not modified by correct code during the agents visit to the host, this data can be encrypted and thus protected from the host.

36

College of Engg. Pandharpur

Mobile Agents

6.2 Three-Tier Protection Model:

In order to protect the code of the agent from possible attacks of malicious hosts, a combination of code mess-up, encryption and limited lifetime of code and data (timing), ill help preventing the attackers from modifying the agents code.

If an agent expires, it can either be killed or recharged. Killing the agent will end its task completely. Sometimes an agent is delayed due to network problems; so killing an agent when its time expires will prevent it from performing its intended task. That is why, agent recharging can be employed in order to allow the agent to migrate further. The problem with this approach is that the agent has to be assigned with a new expiration date and signed digitally by a party that the agent trusts. Also, the agent needs to get a new identity, and the tokens have to be replaced by new ones. All of these requirements have to be performed by a trusted host. The expired agent first checks the identity of the trusted host, and then it delivers the tokens that have to be replaced and gets new ones instead. Code mess up involves creating a different messed up code that does the same task but with a different inner structure. Also, the data elements will have different obfuscated values. In other words, our aim is to develop a mechanism to transform a normal piece of code to a form, which is less readable and understandable. The mechanism to implement code mess up in this work involves three major parts:

Inserting dummy code

Altering the values of numeric variables.

Altering the values of string variables.

First, Inserting dummy code involves adding dummy classes with functions that have

nothing to do with the agents functionality. This aims to make the code more obscure and complex for any attacker to understand. In other words, if an attacker managed to attack the code, it will not find the direct agents code, rather, it will find a more complex version of the code with many functions and classes. This will force the attacker to spend more time in order to understand the flow of the agents code and its exact functionality. Second, Altering the values of numeric variables involves taking every integer, float, double or any other numeric value and changing its value by multiplying it by a randomly generated seed that is kept in the home server in order to be used later to re-generate the original numerical value of the agent by an inverse operation.

37

College of Engg. Pandharpur

Mobile Agents
Third, Altering the values of string variables involves taking every string value and changing it. For every index in the string, a randomly generated seed that is kept in the home server in order to be used later to re-generate the original string value multiplies its numeric value. This way, the agents code is greatly altered and the attacker will find a hard time to unmess up the code. And even if an attacker managed to unmess up the code, it will take a long time to do so, and here comes the role of the timer to do that. Encryption by itself is a very powerful protection mechanism. There are several encryption algorithms that currently exist. The encryption algorithm used in the implementation is the DES algorithm. This algorithm is proved to have a reasonable key length, and is supported by the Java security classes. The main aim of using encryption is to protect the agents important information. In this work, the agents important data is mainly stored in the list of prices that the agent collects from host to host. Thus our main goal is to protect this list using encryption. But again, Encryption alone does not guarantee a full protection for the agent.

38

College of Engg. Pandharpur

Mobile Agents

LIST OF FIGURES

1.3.1 1.3.2 1.4.1 1.4.2 1.4.3 2.1.1 2.1.2

Mobile Agents Reduce Network Load Mobile Agents Allow Disconnected operation Client-server Paradigm Code-on-demand Paradigm Mobile Agent Paradigm MASIF Region concept MASIF Agent system with places, agents and communication infrastructure 7

4 5 6

7 14 14

3.1.1 3.2.1 3.2.2 3.2.3 3.3.1 4.2.1

Remote vs. local agent-resource interaction A mobile agent system Java based mobile agent system Structure and services of a Grasshopper agency The monitoring agent system Architecture of MAN

15 17 18 19 21 29

4.3.1

MAN over TCP and UDP

32

39

College of Engg. Pandharpur

Mobile Agents

ABBREVIATIONS

API ASDK CORBA DCOM GUI IDL IIOP JDK JVM MA MAEE MAN MAP

Application Program Interface Aglet Software Development Kit Common Object Request Broker Architecture Distributed Component Object Model Graphical User Interface Interface Definition Language Interoperable Internet Object Request Broker Protocol Java Development Kit Java Virtual Machine Mobile Agent Mobile Agent Execution Environment Mobile Agent Based Network Management Mobile Agent Producer

40

College of Engg. Pandharpur

Mobile Agents
MASIF OMG PDU RMI RPC SNMP SSL TCP/IP UDP URL Mobile Agent System Interoperability Facility Object Management Group Protocol Data Unit Remote Method Invocation Remote Procedure Call Simple Network Management Protocol Secure Socket Layer Transmission Control Protocol User Datagram Protocol Uniform Resource Protocol

REFERENCES

1. 2.

J. Schiller. Mobile Communications. Addison Wesley, 2000. But Bates, Wireless Networked Communications, McGraw Hill International, 1994.

41

College of Engg. Pandharpur

Mobile Agents
3. Jonathan Nudsen, Wireless Java: Developing with Java 2 Micro Edition, A press Publication, 2001. 4. 5. 6. Wireless Java in A Nutshell: A Desktop Reference, OReilly Publications. Charles Perkins. Mobile IP. Addison Wesley, 1999 Lange, D.B. and Oshima, M.: Programming and Deploying Java Mobile Agents with Aglets, Addison-Wesley, 1998. 7. 8. 9. Danny B. Lange. Mobile objects and mobile agents: The future of distributed computing. Aglets Specification 1.1. IBM Corp., 1998. URL: http://www.trl.ibm.co.jp/aglets Network efficient mobile agent applications using concordia. URL: http://www.meitca.com/HSL/Projects/Concordia/whatisit.htm. 10. 11. 12. The Agent society homepage, web page, URL: http://www.agent.org The Advent Net Library, URL: http://www.adventner.com. Neeran Karnik, Security in Mobile Agent Systems,

URL: http://www.cs.umn.edu/Ajanta

42

College of Engg. Pandharpur