Project Details

3.1 Problems with Implementation of Mobile agents

• Transportation: How does an agent move from place to place?

This problem is actually two-fold. The first is that how does a receiving host executing an incoming agent object when even the name of the class is not known. Secondly, how should the byte code and the serialized agent be securely transferred from node to node.

• Authentication: How do you ensure the agent is who it says it is, and that it is representing who it claims to be representing?

This is one of the main problems with mobile code. A agent has to be authenticated and trusted for it to execute some code on a user machine. This problem is not very severe if the agent system does not use alien agents but uses trusted agents only. For example a groupware software running within a company intranet and accepting only trusted agents within the firewall boundaries can relax the security concerns of accepting agents. But if the domain of operation for the agents is a widely distributed network like the Internet, then the security concerns increase by the order of several magnitudes.

• Secrecy: How do you ensure that your agents maintain privacy? How do you ensure someone else does not read your personal agent and execute it for his own gains?

An agent should be able to carry sensitive information and the design should be robust enough for the agent to protect its data in case some malicious elements try to obtain it.

• Standardization: Should a standard be developed for agents to locate & communicate with each other?

There has to be transfer protocol developed so that unknown hosts can transfer agents to each other.

3.2 Design and implementation

3.2.1 Design of the Agent Host:

The Agent Host architecture consists of the following classes:

· AgentServer

· AgentSpawner

· IncomingRequestMonitor

· RequestServicer

3.2.2 Roles played by each of the above mentioned classes:

· AgentServer: The class that initializes and sets up the IncomingRequestMonitor class in a separate thread of execution.

· IncomingRequestMonitor: This class listens for incoming requests for agent transfers. Once a request comes in, it spawns a new thread of execution of class RequestServicer to service the incoming request. IncomingRequestMonitor also implements the AgentEventListener so that it is informed of the various agent activities like "Agent arrived", "Agent authenticated", "Agent started", "Agent stopped" etc. These captured events are then passed on to the GUI for display to the user.

· RequestServicer: RequestServicer is the class that follows the agent transfer protocol and brings in the incoming agent. Its other responsibilities are authenticating the agent and verifying the signatures. See the section on agent security for more details. Then the agent has to be started by calling particular methods within the agent body. Finally the next destination is obtained from the agent and the AgentSpawner class is called to dispatch the agent to the next node.

· AgentSpawner: AgentSpawner is the class which actually sends an agent to a remote host. It sets up a socket connection to the remote host and follows the agent transfer protocol for the actual transfer of agent code and data.

3.2.3 Agent Design

Agent is a purely abstract class having some method declaration. Users wishing to write their own agents will have to:

1. Inherit their customized agent from the abstract class Agent and implement all the methods
2. The main agent task will have to be put in a method called run. This is the method which shall be called by each receiving host while starting the agent thread.

3.2.4 Security Issues

We use digital signatures for overcoming the problem of agent authentication. Every agent is assigned a digital signature at the time of spawning. Also a message digest is calculated at the time of generating the signature and stored with the agent.

Whenever a host receives an agent, first the signature verification is done using the public key of the agent. Once this is done, then the message digest is verified to be the same.

These checks ensure answers to two questions:

1. Is the agent really coming from a source from where it says its coming?
2. Has the agent source code been tampered with after it was dispatched from the origin location?

Besides this, there are other security issues. Once an agent has arrived on a machine and begins executing, there should be some security measures which disallow the agent to do any damage like open new socket connections, delete files, spawn new threads or engage in denial of service attacks. Installing a SecurityManager class for each agent can prevent these kinds of attacks. The SecurityManager in java can be customized for each agent, probably depending from whether the agent’s owner is a trusted or a untrusted source.

3.3 Agent Transfer Protocol

Step 1: If a host wishes to initiate a agent transfer, then first the next host IP address is obtained from the agent and a socket connection is established with the destination host

Step 2: Once a socket connection is established then the sender host sends an AgentIdentity object that consists of information about the agent.

Step 3: The receiver receives the AgentIdentity object and replies with a ResultObject that contains information about the receiver host’s decision to accept or not accept the agent.

Step 4: If the receiver host has given a positive response in the ResultObject, then the sender host sends the actual agent in the following two steps:
· First the agent byte code is send. The receiver receives this byte code and places the class file into its own classpath. This step is necessary because when the serialized agent is received, then the receiver has the class file for the necessary typecasting.
· Secondly, the actual serialized agent object is send using the object serialization technique of Java.

Step 5:
The socket connections are closed and the receiver host starts the agent on its own machine. After the agent activities are done, then the receiver calls a method on the agent to obtain the next host IP address and repeats the above steps to transfer the agent to that location.

3.4 A Simple Application using Mobile Agents

In order to demonstrate the potentials of mobile agents, we consider a simple real-life application. Consider the scenario of a telephone company wishing to bill its customers at the end of the month. Using the agent architecture, the telephone company would send a Bill Agent to each of its customers to inform them of their outstanding balance. After the users know the amount they owe, they have the ability of dispatching a Transfer Agent to their bank that debits their account by the requisite amount and credits the telephone company’s account.

The user can also dispatch an Info Agent that travels to the bank and asks the bank server to query the database at the bank to find out the user’s bank balance. It then moves on to the telephone company and asks the server at the telephone company to find out how much money the user owes. The Info agent then returns back to the user and gives him all the information.

Care is taken to authenticate the agent using digital signatures. Each host has the option of rejecting an unwanted agent. In addition, all the agents return to the entity that had originally dispatched it.

3.5 GUI Screen Shots

Figure 1: Main GUI window

Figure 2: Agent Activity Monitor

Figure 3: Bill Agent Reporting

Figure 4: Info Agent Reporting