1 Mobile Agents. 2 What is a Mobile Agent? 2.1 Mobile agent = code + state

Transcription

1 1 Mobile Agents And now for something completely different. To date, we have concentrated on programming the network with what can be termed traditional techniques. Specifically, the use of the client/server model is so common that one could be forgiven for assuming it is the only usable network application development model. Today, the vast majority of Internet-based applications conform to the client/server model. And for good reason: it works well, is well understood and is easy to work with. However, there are other models. Of them all, one of the most interesting is the mobile-agent model. 2 What is a Mobile Agent? The cute answer is: it depends on who is asked. Due to the relative immaturity of this field, the study of mobile-agent technologies has produced a number of often conflicting definitions. Rather than discuss the various definitions and risk confusing the reader, a simple working definition is presented here (with the keywords emphasized). A mobile agent is a network-aware software application that can, under certain circumstances, suspend its execution on one network device, transport to another network device and resume execution there. The mobile designation is due to the software application s ability to relocate from one network device to another. The agent designation is due to the software application doing something on behalf of a user, that is, it acts as an agent for the user. This model is very different to the client/server model. Instead of a standard, formatted message being sent from one software application to another over a network, the entire software application is sent. In the course of its execution, a mobile agent may relocate to multiple network devices, that is, it can roam. 2.1 Mobile agent = code + state A mobile agent has two main components: code and state. Obviously, in order for a software application to relocate from one network device to another, its code has to travel. It will depend on the mobileagent environment whether or not the code is in source code form, compiled form or in some intermediate form (such as bytecode). The software application s state also has to travel. This refers to the resources the software application is currently using. Do any variables exist, 1

2 and what are their values? Are any disk-files open? Does the software application hold any other resources? Again, depending on the mobile-agent environment, none, some or all of the software application s resources may travel. The entire set of resources are referred to as the software application s state. 2.2 What is a mobile-agent environment? A mobile-agent environment (MAE) is a set of technologies that provides a working space for mobile agents. The MAE has to exist on each network device that the mobile agent can execute on (and relocate to), and this includes the device that starts the mobile agent. Throughout this document, the device that starts the mobile agent is referred to as the initiating network device. The technologies used to provide an MAE vary widely. Some are network servers that operate on any compatible network device, while others are entire operating systems built from scratch to support mobile agents. Within the literature, MAEs are referred to by a number of names, with site, location and place the most popular monikers. 3 Mobile-Agent Examples In light of an understanding of what a mobile agent is, let us revisit two traditional applications and consider their re-implementation as mobile agents. 3.1 Revisiting multiwho Chapter 4 of Programming the Network with Perl includes the multiwho program, which uses the TELNET protocol to automate the production of the list of logged-in users on a collection of network devices. The TELNET protocol is classically client/server, whereby the server on a remote network device provides a terminal emulation service to a local client program. The multiwho program, built to exploit TELNET, contacts a list of network devices (each of which runs a TELNET server) and interacts with them in order to determine the list of logged-in users. It is the responsibility of the multiwho program to monitor the entire execution process, as well as process the results of each interaction and produce the concatenated list of logged-in users (the master list). The multiwho program exhibits two identifiable characteristics as follows. It is client-centric the client-side of the interaction does all the real work. In comparison, the server-side of the interaction provides a fixed 2

3 set of services which cannot be easily changed or expanded. If additional processing of the results generated by the service request is required, then this processing must occur on the client (as is the case with multiwho). It is bandwidth-intensive the network traffic generated by multiwho in relation to the results produced is disproportionate. A small amount of output results from a large amount of network traffic. This is worsened by the fact that TELNET is a very chatty protocol. A mobile-agent implementation of multiwho would begin by relocating to the first network device on the list. Once there 1, multiwho would determine the list of logged-in users and concatenate them with the master list (which would have started out empty). The multiwho mobile agent then relocates to the next network device on the list and iterates. This procedure repeats until each network device on the list is visited and the master list of logged-in users is complete. The multiwho mobile agent then returns to the initiating network device and displays the entire list of logged-in users. The mobile-agent-based multiwho is no longer client-centric, nor is it bandwidth-intensive. Network traffic is generated when a relocation from one network device to another occurs. Thankfully, the chatty TELNET protocol is nowhere to be seen. 3.2 Revisiting ipdetermine Chapter 5 of Programming the Network with Perl includes the ipdetermine program, which uses SNMP to determine a list of routers contactable from a specified routing device. The technique employed requests the contents of the routing table from a Managed Device, then processes the table to extract the required information. Typically, the routing table has tens (and sometimes hundreds) of entries, which are transferred from the SNMP server (the Managed Device) to the SNMP client (the Management Station) for processing. Like TELNET, the SNMP technologies are client/server. The ipdetermine program is both client-centric and bandwidth-intensive. Returning to the example invocation of ipdetermine from the end of Chapter 5, when executed against the router, it produced a list of just four contactable routers from the entire routing table (which had considerably more entries, 312 in all). Now, imagine a mobile-agent-capable router exists 2. An ipdetermine mobile agent transfers itself to the router, processes the routing table to 1 Note that the mobile agent is no longer executing on the initiating network device. 2 That s a big if. 3

4 determine the list of contactable routers, then returns to the initiating network device with the list. The entire contents of the routing table are no longer transferred across the network, and the reliance on SNMP is greatly reduced. An improved implementation of the ipdetermine mobile agent would involve ipdetermine cloning itself prior to its transfer to the router. The original ipdetermine mobile agent would then wait (on the initiating network device) to receive the results produced by its clone and sent to it from the router. The clone never returns to the initiating host, only the results of its execution on the router are transmitted. In this way, the network traffic generated by the clone is kept to a minimum. 4 Mobile-Agent Advantages/Disadvantages Before discussing the advantages of the mobile-agent model over others (notable the client/server model), it is important to point out that it is possible to use any development model to solve a problem. The client/server and mobile-agent versions of both multiwho and ipdetermine solve the problems they set out to. The methods used are very different, but the results are the same. The trick is to identify when it is appropriate and advantageous to use one model over the other. It might seem obvious, but the fact that mobile agents have the ability to relocate is a huge advantage. For example, if a mobile agent cannot find what it needs on one network device, it relocates to another and continues looking. As such, the mobility advantage removes some of the limitations of traditional techniques. The mobile agent can, therefore, make the most of its autonomy. Related to the mobility advantage is the ability of a mobile agent to adapt to the job at hand, providing a potentially powerful problem-solving technology. Granted, this typically involves combining mobile-agent techniques with those of the Artificial Intelligence community 3. The adaptability advantage provides a level of customization which is superior to other models. When mobile agents collaborate at locations, this advantage can enable unique and elegant solutions to problems. Efficiency is another advantage, especially as it relates to network bandwidth utilization. As the complexity of the mobile agent increases, the bandwidth requirements do not necessarily. As an example of the efficiency advantage, consider a website indexing program. When developed using traditional client/server techniques, one possible strategy employed by the client would be to request every document accessible on the website. Each document is retrieved from the HTTP server (with its own individual HTTP Request) and then stored on the 3 A topic very much beyond the scope of this document. 4

5 client s local storage. Only then can indexing occur. Even when HTTP/1.1 (with its persistent connections) is employed, the network traffic produced by this strategy is large, and gets larger as more documents are added to the website. The resulting index might be small, but, as this is produced on the client, its size has no bearing on the network bandwidth used. When a mobile-agent strategy is employed, the mobile agent relocates from the initiating network device to the website and performs the indexing in situ. When the index is created, it is transferred back to the initiating network device. The index is small and the bandwidth that it consumes pales in comparison with that generated by the client/server approach. Granted, the processing burden (that is, the creation of the index) has been shifted from the initiating network device to the website. But, bear in mind that the website no longer has to process all those HTTP Request messages, as it is assumed the mobile agent has access to the website s documents in a manner which is independent of the HTTP access mechanisms. The web-indexing example also serves to highlight the major disadvantage of using mobile agents: security concerns. For the mobile-agent model to work well, all of the participating network devices must trust each other to a high degree, or to a level of trust that is deemed acceptable by some local administrative policy. For instance, it would be foolish to widely advertise the existence of an MAE on any network device, as not all users of the network are trustworthy. The problem worsens when one considers that an MAE provides a facility to execute arbitrary blocks of code as received from another remote network device. A malicious mobile agent could wreak havoc on the network device hosting the MAE if given free rein to execute any code on the MAE. Another concern is the existence of malicious MAEs which await the arrival of non-malicious mobile agents. When they arrive, these mobile agents find themselves operating in a hostile environment. Any further discussion of the solutions to the security disadvantage are beyond the scope of this document, as the intent here is to introduce the mobile-agent model and demonstrate examples of its use. Security in mobile agents is generating considerable ongoing research among academics and commercial interests. 5 Perl Agents The application of Perl to the development of mobile-agent technologies has, unfortunately, not produced a great wealth of activity (as compared with the other networking technologies studied). Despite this fact, the area does have its pioneers. One such pioneer is Steve Purkis, who, as an undergraduate at Carleton University in Canada, developed the Agent.pm module. An unfinished, proof-of-concept technology, Agent.pm can nevertheless be used 5

6 to develop working mobile agents in Perl. Another technology is Scooby 4. Refer to the Scooby website for more information at scooby/. 4 Just why it is called Scooby is a bit of a mystery... groan. (Or maybe that should ve been woof!).g 6