The Use of Software Agents as Proxies B. Thai, A. Seneviratne School of Electrical Engineering and Telecommunications University of New South Wales, Sydney, Australia
[email protected],
[email protected] Abstract Today information can be accessed from the Internet using a variety of devices and via different types of networks. With such diversity, it is impossible for a server on the Internet to contain information for all different types of clients. A possible solution to this problem is to use proxies to alter the content and to provide network enhancements to suit client’s individual requirements. The current proxy-based solutions rely on static implementations which have several disadvantages. We believe that it will be possible to overcome these disadvantages by making the proxies transportable and active, ie. the use of proxy agents. In this paper we present the architecture of such a proxy agent system, and the implementation of a prototype to evaluate its viability.
1. Introduction Internet clients today can access the Internet using a variety of network technologies. The different types of host systems have different characteristics in terms of bandwidth, network latency and jitter. The end devices also have very different capabilities. In addition, devices can potentially have more than one method in accessing the network. For example, a notebook computer can gain access to the Internet by using either a modem, fixed wired Ethernet, wireless LAN, or GSM. In such a heterogenous environment, it is not possible for a server on the Internet to contain information to cater for all types of clients. One possible solution to the above mentioned problem is to use proxies to dynamically alter the content and to provide network enhancements to suit client’s operational environment. There are a number of frameworks which use this concept [4],[5]. All these schemes assume that it will be possible to use a dedicated network node as a proxy server to provide the required functionality, as the mobility management will be handled by the data link layer. Furthermore, these assume that the client applications will be able to support the use of proxies, and that the users will be capable of
manually configuring the clients to use the different types of proxies. However, firstly, if the users roam between different network types it may not be viable to use a static proxy server architecture. Secondly, as the applications use different types of media, the manual configuration process will be at best tedious. We believe that it will be possible to overcome the above limitations of proxy based solutions by making the proxies transportable and active, ie. the use of proxy agents. In this paper we present the architecture of such a proxy agent system, and the implementation of a prototype to evaluate its viability.
2. Related work The concept of placing proxies between the server and the client is not revolutionary. Currently there are many HTTP proxy servers on the Internet which perform the function of content filtering and caching frequently used web pages [11]. Caching reduces network traffic as those web pages can the fetched locally rather through the Internet. Consequently, clients can access the information faster. The use of proxies for transcoding has also been addressed. In [3], Chandra et al uses a dedicated proxy server to perform the image reduction. Their results show that the size of the image can be reduced, hence improve download times over slow links (9600 and 28800 baud modems). Similarly, Fox et al [5] make use of a proxy that performs transcoding. Their results are similar to Chandra’s, and show that reducing the quality of the image, text, audio and video, the latency over slow links is reduced. They also showed that the latency introduced due to the transcoding process is only a fraction of the overall latency. This implies that an appropriate transcoding algorithm does not introduce a penalty in terms of processing latency over slow links. The use of proxies is not restricted to transcoding. Appenzeller et al [1] employ personal proxies for message routing. Messages coming from any device, such as email or telephone, are routed to the user-specified device via the receiver’s personal proxy. When necessary,
protocols can also be converted. This enables a person with multiple network enabled devices to be reached using one identification number. At the same time, the location of the person is completely hidden from the sender. The personal proxy can also perform message filtering. Although the above mentioned frameworks use proxy based solutions, the proxy system is static, i.e. uses a static proxy server with proxies resident on it. Thus these frameworks cannot obtain any addition proxy functions dynamically and they are not tailored for load balancing.
2.1. Agent technology Software agents are programs that assist people and act on their behalf [9]. Agents are gaining popularity among software designers because this concept is considered to be the next step from object-oriented paradigm. There are two major classes of agents: static and mobile. The difference between the two is that a static agent executes on the system where it begins execution [9]. A static agent gains information from another system by using existing communication mechanisms such as remote procedure call (RPC). This differs to a static process in a system in that the code of a static agent is loaded from the network on-demand, whereas static processes have their code stored locally within the system. On the other hand, a mobile agent can suspend its execution while it is executing on one system, migrate to another system, and continue its execution from the point of suspension. Software agents are used in various areas in telecommunications. La Porta et al. [7] enhance the functionality of two-way messaging services and Personal Communication services (PCS) by employing static and mobile agents respectively. By using a static agent as a gateway between pagers, the architecture of the pagers can be remain simple while obtaining full-duplex messaging capabilities. Mobile agents are used in the PCS system to maintain the state of the current user, such as the user’s device and its service profile. As the end client move from one cell to another, because the agent is mobile, it can autonomously follow the user to the new cell and still maintain the user’s status. Agents have also been used in network management [10]. These method reduces not only the network traffic, but also the computational load on the managing system, since the necessary computations are distributed among network element. The second method is the use of mobile agents, which the management system sends a mobile agent to each network element. When it returns to the managing system, it report results.
As can be seen from above examples, software agents, both in the forms of static and mobile, can be employed successfully in different areas of telecommunications. Therefore, it should be possible to combine the proxy functions with software agents.
3. A framework to use agents as proxies for session customisation As mentioned previously, static proxy server based approach lacks flexibility. Our approach of using agents as proxies removes that limitations of static proxy schemes. The idea is to embed the functionality of proxies into software agents. By encapsulating proxy functions within different agents, the “proxy server” can dynamically request the necessary proxy agents to perform the appropriate operations for each client. Furthermore, it provides inherent load balancing functionality. This approach is completely different to Active Networks as all the functionality is provided above the network layer.
3.1. Session Customisation With proxy-based solutions, the servers store the content with the highest information density. Depending on device limitations and the characteristics of the available network, appropriate proxies are used to reduce the content, or enhance the network service to meet the pre-defined parameters of the client. Our work concentrates on bringing dynamicity into these proxy based customisation architectures. To facilitate this, the following assumptions about the operating environment are made: • Within the network, instead of having dedicated proxy servers, some network nodes will provide access to computing resources attached to it on which proxies can reside and execute. We call these computing resources compute servers. • The compute servers will be capable of downloading proxies functions from a secure proxy repositor. Furthermore, the proxy functions are encapsulated in either a static or a mobile agent.
3.2. Typical Operational Environment To illustrate how our approach can fit into existing networking environments, we will provide a typical operational scenario. Let’s assume we have a streaming video server, a file server and two clients, one is accessing the network using a 56.6k modem, connected via a typical ISP, and the other is using a wireless LAN. Since we have two clients with different bandwidth available to them (modem –
56.6kbps, typical wireless LAN – 2Mbps), proxies are required to reduce the content’s data rate to suit each client’s operating environment. Within the network, we have several compute servers, and a “store” which hold a proxy agent which does the necessary transcoding to reduce the streaming video stream to fit to a 2 Mbps and a 56.6kbps channel. This is illustrated in Figure 1.
Mobile Client
Compute Server 2
High quality video
Compute Server 3
Internet Streaming Video Server
Compute Server 1
ISP
Modem File Server
In general, the assumption of the bandwidth available in the backbone network is high compared to the wireless or modem tails is valid; however, the user may have to pay for the bandwidth that it consumes. Therefore, if bandwidth that is consumed on the backbone can be reduced, not only it will help reduce network latency caused by network congestion, it will also reduce the cost for the client. Hence the transcoding need to be performed as close to the server as possible. With our approach, to set up this session, Computer Server 1 will download the proxy agent from the Agent Proxy Store. The High quality (and therefore high data rate) video stream will pass through Compute Server 1. The proxy agent in Compute Server 1 transcodes the high data rate video to lower rate video and deliver that stream to the static client via the ISP. This is illustrated in Figure 3.
Static Client
Proxy Agent "Store"
Mobile Client
Figure 1. A typical operational environment
With the exception of the additional Proxy Agent “Store”, the environment as shown in Figure 1 is similar to the environment used with the employment of the dedicated proxy server solution. Given such an environment, there are a number of operational scenarios are possible: Scenario 1: A streaming video session with the static client Under the current static proxy server scheme, this point to point session will have a transcoding proxy placed in the ISP, ie. close to the static client. If the ISP does not have the transcoding function to transcode the video stream to 56.6kbps, then the static client will not be able to watch the video. Even if the ISP has the transcoding function, the transcoding does not occur until the video reaches close the client. This implies that high data rate video stream is transmitted across the Internet. Figure 2 illustrates this typical scenario.
Mobile Client
Compute Server 2
Streaming Video Server
Compute Server 1
Compute Server 3
2. The ISP with the transcoding proxy reduces the data of the video stream.
1. High data rate video is streamed to ISP ISP
Low data rate video stream
Internet Modem File Server Static Client
Proxy Agent "Store"
Figure 2. The ISP act as a proxy server.
2. High data rate video is streamed to Compute Server 1
Compute Server 2
Compute Server 1
Compute Server 3
3. The proxy agent transcodes the video to lower data rate content and sends it to the client
Streaming Video Server
ISP
Low data rate video stream
Internet File Server
1. Compute Server downloads the static proxy agent
Modem
Static Client
Proxy Agent "Store"
Figure 3. The set up of a streaming video session for a static client.
Scenario 2: A File Transfer Session with the Mobile Client. As the mobile client is accessing the network via a wireless link, to improve the performance of the TCP connection between the file server and the mobile client, performance enhancing proxies are required. According to [2], over a wireless link, performance enhancing proxies not only can improve the performance of the link, but also keeping the TCP connection alive while the mobile client is disconnected from the network for a period of time. In this scenario, Berkeley’s Snoop protocol [2] can be used to improve the performance of the wireless link. A Snoop proxy is placed in the last hop router to the mobile client. From Figure 1, the last hop to the mobile client is Compute Server 2. During file transfer, the Snoop proxy caches any unacknowledged TCP data and forwards it to the mobile client. The proxy also monitors the corresponding ACKS. If any retransmissions are required, the retransmissions are performed locally to
avoid end-to-end retransmissions. This is illustrated in Figure 4. Mobile Client 2. Data is transferred from Compute Server to Mobile Client
Snoop Proxy is placed here
P
3. Mobile Client Mobile Client r o a m s t o a n o t h e r network Mobile Client 2. Data is originally 6. data is transferred from 4. The mobile transferred to the Compute Server to proxy agent client from Mobile Client moves with the Compute Server 3 client Compute P Server 2 Compute
1.Data is transferred from file server to Compute Server 2
Compute Server 3
Streaming Video Server
1.Data is transferred from file server to Compute Server 2
Compute Server 1
Server 3
Snoop Proxy was here
Compute Server 2
Streaming Video Server
Compute Server 1
5. data is now transferred to Compute Server 3 ISP
ISP
Internet Internet
Modem Modem
File Server
File Server
Static Client
Static Client
Proxy Agent "Store"
Proxy Agent "Store"
Figure 4. A file transfer session with the use of a Snoop proxy.
The current arrangement only works well if the mobile client does not roam between networks. If the mobile client moves from one network to other, given that the Snoop proxy is static, the only method to deliver the TCP data to the client is to re-route the data via another host. This is illustrated in Figure 5. 3. Mobile Client Mobile Client r o a m s t o a n o t h e r network Mobile Client 2. Data is originally transferred from 4. data is now 5. data is routed Compute Server to routed to to Mobile Client Mobile Client Compute Sever 3 via from Compute Server 3 Snoop Proxy is P Compute placed here Server 2 Compute Server 3
Streaming Video Server
Compute Server 1
1.Data is transferred from file server to Compute Server 2
ISP
Internet Modem File Server Static Client
Proxy Agent "Store"
Figure 5. The re-routing of data as the mobile client roams between networks.
The method of re-routing data is ineffective, as the snoop proxy now is no longer close to the mobile client. A more effective approach is to encapsulate the Snoop proxy function in a mobile agent. When the mobile agent roams to another network, the mobile agent proxy moves with it, taking along its session states, eg. cached TCP data. This way the Snoop proxy can be close to the mobile client all the time. This is illustrated in Figure 6.
Figure 6. The use of a mobile proxy agent with the mobile client.
3.2. The use of static and mobile agents As shown with the above scenarios, by simply applying static agents alone is not enough. Both types of agents have their advantages over the other, but they also have their shortcomings. Static agents have the following advantages: • Security – since the agent is downloaded by the compute server, the compute server can authenticate the agent before downloading. The compute server can refuse to download an untrusted static agent. • Ease of proxy location – because the placement of a static agent is determined before the session begins, and because they do not move throughout the session, it is easy to locate a given proxy during a session. • Greater functionality – as a static agent does not migrate between compute servers, it can encapsulate more proxy function codes than a mobile agent. The penalty of having more functionality in a static agent is a higher session setup time, since it will take longer for the compute server to download the code. Static agents also have the following shortcomings: • Lack of session flexibility – once the session is set up, it is impossible to dynamically change the characteristics of the session. To do so, one must destroy the current agent to reload a new one. This is undesirable as a new agent will not have any information about the states of the current session. Mobile agents have the following advantages: • Mobility – mobile agents can follow a roaming client with greater ease than the static counterparts. This means a mobile agent can always be as close to the client as possible. This can reduce the number of hops when content is delivered from the server to the client. • Load balancing – potentially a certain compute server may get heavily loaded, both in terms of CPU usage and
network traffic around the computer server. If mobile agents are used, certain mobile agents can be asked to migrate to another compute server without affecting the client’s session greatly, thereby effectively distributing the load among the compute servers • Co-operation between agents – a mobile agent may not have the necessary capability to perform a task by itself. Under these conditions it may be possible for, a mobile agent to migrate to another compute server and cooperate with existing mobile agents on that compute server to complete the task. Once the agent has moved, all communications between the agents are performed locally, thereby reducing network traffic. However, mobile agents also have the following shortcomings: • Limited functionality – since a mobile agent is required to migrate while a session is in progress, the mobile agent needs to be as light as possible to reduce the delay involved for session re-establishment. This requirement reduces the functionality that could efficiently supported by a mobile agent compared to the static counterparts. Because of the relative the advantages of both static and mobile agents, both forms of agents are used into our framework, which allows us to use one form of agents to overcome the disadvantages of the other form.
4. Prototype implementation As the Internet is heterogenous in terms of software and hardware architecture, it will be difficult to design and implement agents using native code; however, using native code does provide the best performance in terms of code execution. In [7], the agents are implemented using C++ under a UNIX platform. We believe that an agent platform that is architecture independent will provide greater flexibility. This makes Java a suitable candidate. Java has several features which suits our framework, namely Remote Method Invocation (RMI) and object serialisation [6]. We do not need to implement a mobile agent platform ourselves, as there are several mobile agent platforms available at which we can utilise.
4.1. Mobile agent platforms Nearly all the mobile agent platforms available are written in Java, such as IBM Aglets, Concordia, Voyager and Odyssey. All of these platforms exploit the feature of object serialisation of Java for the mobility of the agent. IBM Aglets is used for our implementation and experiments. It is simple in that it provides various predefined methods by which the developer overrides. Each aglet runs in its own thread of execution inside an environment known as a context. Aglets communicate
with each other by the use of message passing. This communication can be performed between aglets within the same context or between different contexts over a network. As the objective of this work was to realise a proof of concept implementation, other mobile agent platforms are not considered.
4.2. Experimental environment By using Java and IBM aglets as our basic platform, we have implemented a prototype. Our current environment consists of 3 Linux PC’s. The PC’s are connected together with 10Mbps Ethernet. We are currently using the sample context called tahiti, which is supplied with the IBM development kit, as our mobile agent server. A gateway is also installed to allow the PC’s to obtain information from the Internet. Our experiment with aglets was to simulate a dynamic load balancing. Our aim was to prove that application states can be preserved within the mobile proxy agent. The experiment is as follows: • A source process is written to simulate a server. When invoked, it makes a TCP connection to the proxy, which is in the form of a mobile agent. The assumption is that all processes know the IP address of each other, even after the proxy has moved. • A proxy agent is implemented, with a proxy function of converting upper case characters to lower case. Once the proxy is created within the aglet context (tahiti), it makes a TCP connection to a sink process. The sink process is written as part of the signalling protocol used for resuming data transfer, and to print out results. • Once the connections are established, the source process sends a sequence of ASCII characters to the sink via the proxy agent. • During the transfer of characters, the proxy agent is interrupted. This interruption signals to the proxy that it has to move from one aglet context to another. The second aglet context (which is another tahiti server) is located in another host (Linux PC 2). The proxy agent breaks its TCP connection with the source and the sink processes. Both the source and the sink detects the break of their connection with the proxy agent, and wait for a period of time and attempt make a new connection with the proxy agent after it has migrated. The period of time of which the source and the sink process waits is determined by the time it requires the mobile proxy to migrate from one host to another. • The proxy agent migrates to remote host. The TCP connections are re-established. As soon as the connections are re-established, the source continues to send data to the sink, resuming from the point at which the connection is broken. This is illustrated in Figure 8.
3. The source seized its transmission as soon as it detected the break in the connection
1. The Proxy Agent is interuptred by the press of a return key
Source Process
5. Once the connection is re-established, transmission continues from the point at which it was interrupted.
4. The proxy agent arrived to the new conetext and immediately reestablishes the connections to the
Aglet Context (Tahiti) Proxy Agent
Sink Process
2. With the interruption, the proxy agent breaks all the connection and migrate itself to another host
Aglet Context (Tahiti) Proxy Agent
• Add at least one proxy repositor into the framework, which stores all the proxy function in the form of static and / or mobile agents. We have pointed out the reason behind the use of both forms of agents, as we are trying to use the advantage of each form of agents to cover the other form’s disadvantages. We have also illustrated this with various examples. As this concept is still in its early stage, there are still a number issues we need to address; however, we believe that this provides a flexible solution to any proxy based framework for customising a session to cater for the operating environment and client requirements.
6. Acknowledgments
source and the sink
Figure 8. The migration of the Proxy Agent.
4.3 Observations and findings The above experiment shows that a TCP session can be kept alive while the mobile proxy agent is migrating from one host to another and maintaining certain session states. However, we also discovered that although a mobile agent is capable of carrying its execution states during migration, there are certain states it cannot carry, namely the states of an opened socket. The socket states are maintained by the operating system, and therefore they are not easily accessed by any user level processes. Hence in order to perform our mobility experiment, we had to break all TCP connections and re-established them after the agent proxy was migrated to another host. We achieved this by applying some end-to-end signalling protocol based on SLM [8]. We realised that any states below the session layer cannot be carried by a mobile agent; however, we can keep various states at the session layer. These states can be carried by a mobile agent as part of its execution states during migration.
5. Conclusions In this paper, we have introduced the concept of employing static and mobile agents as proxies to perform the function of content alteration and network enhancement. The advantage of this approach over the use of a dedicated proxy server is that it allows an intermediate network node to obtain some proxy functions that it does not have locally. We have also shown via an example that our approach can fit into any proxy based framework with the following modifications: • Replace any dedicated proxy servers with proxy placeholders known as compute servers.
The authors would like to acknowledge Ericsson Radio Systems AB, Sweden and Ericsson Australia for their financial support, and Eric Yip in assisting the experiment.
7. References [1]
Appenzeller G et al, “The Mobile People Architecture”, Technical Report CSL-TR-99-777, Stanford University, January 1999. [2] Border J, Kojo M, Griner J, Montenegro G, “Performance Enhancing Proxies”, IETF Internet-Draft, ietf-pilcpep.00.txt [3] Chandra S, Ellis C, Vahdat A, “Multimedia Web Services for Mobile Clients Using Aware Transcoding”, Proceedings of the 2nd ACM/IEEE International Conference on Wireless and Mobile Multimedia, August 1999. [4] De Silva R, Landfeldt B, Ardon S, Seneviratne A, “Total Management of Transmissions for the End-User, A Framework for User Control of Application behaviour”, HIPPARCH, London, 1998. [5] Fox A, Gribble S, Brewer E, Amir E, “Adapting to Network and Client Variability via On-Demand Dynamic Distillation”, Proceedings of 7th Intl. Conf. on Arch. Support of Prog. Lang. And Oper. Sys., Cambridge, MA, Oct 1996. [6] Java homepage, http://java.sun.com [7] La Porta T, Ramjee R, Woo T, Sabnani K, “Experiences with Network-based User Agents for Mobile Applications”, Mobile Networks and Applications 3 (1998), p.123-141 [8] Landfeldt B, Larsson T, Ismailov Y, Seneviratne A, “SLM, A framework for Session Layer Mobility Management”, ICCCN Boston, October 1999. [9] Lange D, Mitsuru O, Programming and Deploying Java Mobile Agents with Aglets, Addison-Wesley, 1998 [10] Magedanz T, Eckardt T, “Mobile Software Agents: A new Paradigm for Telecommunication Management” [11] The Squid homepage, http://squid.nlanr.net
