This paper presents a new technique to improve the performance of remote procedure call (RPC) oriented applications in wireless or other slow network.
Using Mobile Code to Improve Distribution Performance In Slow Wireless Environments Heikki Tienari, Saku Kaukonen and Jaakko Sauvola MediaTeam, Infotech Oulu University of Oulu, PO Box 4500 90014 University of Oulu, Finland
ABSTRACT This paper presents a new technique to improve the performance of remote procedure call (RPC) oriented applications in wireless or other slow network environments. A novel technique based on mobile code is used to minimise the costs associated with RPC calls. The performance improvements are achieved by utilising a mobile agent paradigm to reduce the number of remote method calls sent over an inefficient network. This performance boost is experimentally proved in the HSCSD (High Speed Circuit Switched Data) GSM network environment and the threshold of profitableness is examined. Promising application scenarios are discussed.
1.
Introduction
The Internet offers ever-increasing opportunities to create new services. People have become dependent on access to those services and now technical advancements are beginning to enable the usage of these services also in mobile environments. Mobile terminals, such as laptop computers, smart phones, or handheld devices, are often connected to a fast fixed network via a low-bandwidth, high-delay connection, such as high-speed GSM data (HSCSD, asymmetric bit rates up to 56 kbps [1]) or GPRS (bit rates up to 170 kbps [1]) and, in the future, UMTS (peak bit rates up to 2Mbps [1][2]). Applications designed for faster, fixed networks, usually offering bandwidth in the multi-megabit range, perform poorly when used as such in low capacity mobile environments. Most modern applications, such as database viewers, network games, and Internet telephony, require intensive data transfer between the communicating entities. For mobile users, the closest network link is easily turned into a bottleneck as regards to performance because of the long network delays, lower bandwidth, and partly because
of higher bit error rates. The problems in using TCP/IP over wireless connections have been addressed by, for example, H. Balakrishnan [6] and Kojo et al. [7]. Their approach has been to reduce the unnecessary network traffic caused by TCP/IP itself. The traffic can also be decreased by optimising the RPC technologies to reduce the overhead and by utilising compression techniques in the data transfer. Note that RPC optimisation strategies for slow networks differ essentially from the ones used in high-speed networks. Marshalling time for example is rather essential in high-speed environment but is almost insignificant in slow networks. Campadello et al. have achieved good results in optimising the performance of Java RMI (Java Remote Method Invocation) in a slow wireless environment [8]. By reducing the DGC (Distributed Garbage Collection) and ping traffic they succeeded to achieve, in certain cases, over 200% improvement in the performance. The applications for wireless or low-bandwidth terminals must be designed to cause as little network traffic as possible. This may be achieved by properly partitioning the application logic between the terminal and server(s). Software agent-based application partitioning according to terminal and network characteristics has been examined for example by Koskimies and Raatikainen [9]. Their approach was to dynamically determine optimal execution locations for the agents. Instead of focusing on agent-based applications, our approach is to use a mobile code to enhance the nonagent-based software that generally uses RPC level communication semantics. Also Bakre and Badrinath have examined the possibility to let an agent perform RPC calls on behalf of the client [14]. Their approach, however, was very different from ours: they did not use mobile code, they do not have a generic proxy server, and their primary purpose was to enable dynamic binding of stateless service objects, not to condensate multiple calls into one. In this paper, we will show that better optimisation for call series can be achieved by applying a mobile code design pattern. The amount of RPC overhead and network
delays strongly imply that making one occasional method call with a lot of data is faster to do than a series of smaller, more frequent method calls with an equal or less total amount of data. We exploit this property by using mobile code architecture as described later in this paper. The paper is organised as follows: Section 2 presents an overview of RPC and Java RMI in particular. In Section 3, our RPC pattern based on mobile code is introduced and compared to traditional RPC, and the simple architecture is presented and the application of the mobile code pattern is described. Section 4 illustrates the results and the test arrangement of the experimental performance measurements. Section 5 is a conclusive section.
2.
For every remote call, the RPC mechanism needs to transfer not only the parameter data, but also e.g. the ID of the target object, the name or ID of the method, and possibly also protocol identification and version number. Often the amount of this overhead data exceeds the size of the actual user data. With RMI, the additional data required by RMI itself together with the network latencies introduce considerable overhead for every RPC call, and thus make the system relatively inefficient. Java RMI also has a built-in distributed garbage collection (DGC) feature that causes significant load especially in the service lookup phase [8].
3.
Overview
In this paper, we present a method to increase the performance of distributed RPC-based mobile applications in high delay networks. RPC is an easy and popular paradigm for implementing the client-server model of distributed computing. A typical RPC interaction is initiated by the caller, a client, sending a request message to the remote system, the server, to execute a certain procedure using the arguments supplied. Finally, a response is returned to the caller. In the client’s end the calling thread blocks until the response is received, i.e. RPC is a synchronous messaging schema. RPC is usually applied to achieve different levels of distribution and location transparency for distributed applications. The method presented in this paper can be applied in situations where a client executes a series of RPC calls to the server. We demonstrate our method with the Java programming language and a popular RPC technology named Java RMI (Remote Method Invocation). Both Java and RMI are widely applied in the industry and academia. Many RPC techniques are based on the proxy pattern, where stub classes play the role of the proxy and the remote service implementation is the real objective. In RMI, the stub classes are specific by service implementation: the same stub cannot be used with other implementations of the same service interface. Installing implementation-specific stub classes into the client terminal is not advisable if multiple different service implementations are going to be used. Fortunately, Java RMI offers means to transfer class byte codes, i.e. the executable program code, when needed. This transfer is usually carried out via the HTTP or FTP protocol [3], but this can be quite inefficient, as was concluded in our performance measurements. On the other hand, some RPC mechanisms, such as CORBA, avoid the problem of transferring stubs by defining them as interface-specific rather than implementation-specific, hence removing the need to transfer the stubs’ byte code [4].
Using mobile code to speed up series of remote calls
Our approach addresses the performance problems associated with common RPC technologies in wireless and low-bandwidth, high-delay networks by sending a simple agent-like entity over the slow connection to the fast network. Its goal is to perform the series of remote method calls efficiently, reducing the overall execution time. Although more data is actually sent over the lowbandwidth network, the performance can still be better due to the fact that making a larger method call is more efficient than making multiple small calls. This design pattern can be utilised with any common RPC technique and with any programming language that establishes an easy way to transfer program code. In this paper, we use Java and RMI to demonstrate the pattern. A similar pattern can be implemented by utilising a fully featured agent system, such as Aglets, Grasshopper, or MAF [12][13][5]. If the remote services were implemented as agents, the usage of a fully featured agent system would be justifiable. Our baseline, however, is that the services that are going to be used do offer a conventional RPC interface and are not implemented as agents. Many existing Internet-enabled business applications and enterprise application frameworks are not based on message-oriented software agent technologies but use RPC and object level communication methodologies, such as CORBA and RMI [10][11]. Also with Jini connection technology, the Java RMI is typically used to carry out the remote calls [3].
3.1.
RPC-based communication systems
In this section, we present and evaluate four different computing environment configurations: the traditional client server model, client server with dynamic stub code downloading, client-proxy-server, and client-proxy-server with dynamic agent and stub code transfer. The most straightforward configuration is the traditional client server model where the client, having the
stub classes preinstalled, executes remote calls to the server. In the case of RMI, the client runs remote service implementation-specific code, because the RMI stubs are strictly bound to the remote service object implementation, i.e. they are service-specific unlike in CORBA. A more dynamic variation of this model can be achieved by loading the stub codes from the server as ondemand, e.g. by using FTP or HTTP. Standard Java RMI supports this kind of dynamic stub downloading. To further enhance the performance of multi-call RPC communications, we introduce an agent-like entity that is sent to the proxy server to execute multiple remote calls, as depicted in Figure 1. This method results in fewer method calls over the slow wireless link, potentially increasing the overall performance. The byte code of the agent and remote stubs can already be installed into the proxy server, although this is not very feasible: proxy servers should be kept generic and exclude any application- specific code. Slow Network
3.2.
Fast Network Server
Proxy Client Dispatch agent to proxy RPC call. Multiple Service Invocations
around the client code. Additionally, in situations where a lot of complex program logic is needed between the calls, the size of the agent may grow too large to be profitably transferred. The proposed agent pattern does not replace the use of RPC. Now the agent executes the calls on behalf of the client, while the same RPC interfaces are offered by the same remote services. Applying this agent pattern does not require any changes to the service implementations that are used. With the remote execution of frequent RPC calls, we can also save network and CPU resources in the client and make them available for other applications. This pattern can also be applied in downloading the WWW pages. Loading a WWW page often requires multiple HTTP requests because each image etc. is loaded separately. We can send an agent to the proxy server to execute HTTP calls needed to load a certain page, and it then returns with all the data needed to show that page.
Remote Processing Return value
Return value(s)
The execution time of a method call series with conventional RPC can be estimated by the following formula. The time required to perform a single RPC method call is estimated by a division of the amount of transmitted data (PD+RD+OD) and available bandwidth (LB) and by adding the network dependent delay (LD). If the execution of calls requires downloading stub byte codes, the downloading time should be added to this execution time. (1)
Figure 1.
Basic agent-assisted RPC
To enhance the system, the execution code of the agent and the stubs is dynamically transferred to the proxy. This results in application-independent proxy server implementation. Note that all service-specific code, such as the interface class of a remote service, must be transferred along with the agent. Although byte codes need to be transported over the network, the overall performance is still – in certain cases – better, as we will see later on in this paper. The method promotes the use of generic multi-purpose proxies for the mobile agents, without any application or service specific-code installed. In this paper, the term dynamic agent refers to an agent that is transferred with its code while the use of a static agent means that only the agent’ s state is transferred and the agent’ s code is installed into the proxy server. The usage of mobile agents to perform the RPC calls is especially useful in applications where the sequences of RPC calls are executed and there is no need for accessing fixed local terminal resources, such as the GUI, in the terminal between the calls. The method is not useful in scenarios where individual remote calls are made from
Performance approximation
time = N * (
PD + RD + OD + 2 * LD ) , where LB
N is length of call sequence, PD is size of call parameter data (bytes), RD is size of return data (bytes), OD is overhead data in call and return combined (bytes), LB is bandwidth of slow wireless connection (bytes/s) and LD is slow network path delay (s). The time required to execute the same series of method calls with a mobile code pattern in a situation where the code of both the agent and the stubs is already in the server can be estimated by using the formula 2. The amount of time needed to transfer the agent from the client to the proxy and back again is calculated by a division of the amount of transmitted data (now AS+RO+OD) and the available bandwidth (LB) and by adding the network dependent delay (LD). Now the time required to execute RPC calls in a fixed network can be estimated by a division of the amount of transmitted data (PD+RD+OD) and the available bandwidth (now HB) and by adding the network dependent delay (now HD). (2) time =
AS + RO + OD PD + RD + OD + 2 * LD + N * ( + 2 * HD ) LB HB
, where AS is size of agent’ s state (bytes), RO is size of
return object (bytes), HB is bandwidth of fast network (LAN) (bytes/s) and HD is fast network path delay (s). In a situation where the code of the agent and stub is dynamically transferred to the proxy server, the execution time can be estimated as presented in the formula 3. In this case, the size of the agent (AD, agent and stub code included) is included in the formula (3): time =
AD + RO + OD PD + RD + OD ) + 2 * HD ) , + 2 * LD + N * ( LB HB
where AD is size of the agent including codes (bytes). These equations are used to obtain the result estimates. The processing time needed to actually process the method call or the marshalling and unmarshalling times are not considered. For simplicity’ s sake, it is assumed that the amount of data to send (PD) and receive (RD) remains constant over the call sequence. This theoretical approximation does not include the time to look up a server from the naming service or DGC activities affiliated with the reference fetch. 7000 6000
time (ms)
5000 4000 3000 2000 1000 0 1
2
3
4
5
6
7
number of calls
Figure 2.
Theoretical performance.
The performance of traditional RPC was estimated with the values PD=8 bytes, RD=8 bytes, OD=80 bytes, LB=3600 bytes/s, LD=400 ms using equation 1. The selected values were the same as the ones used in the experimental measurements described later in this paper. The configuration where the byte codes of the agent and stubs are pre-installed into the proxy server was calculated with AS=20+N*PD bytes, RO=N*RD bytes, HB=10 megabytes/s, HD=1 ms (Equation 2). The approximation of the dynamic agent (d-agent) performance was estimated with the values AD=5500+N*PD bytes (Equation 3). The theoretical
8
performance of the RPC technique explored in this paper is depicted in Figure 2. If we divide formula 3 into two parts and calculate agent transfer time and task execution time separately, we can see that the agent’ s transfer time is dominant over the RPC series execution time. For example, when the length of the sequence is five calls, the execution time of the actual RPC calls is about 0.5 percent and the rest 99% of time is spent in transferring the agent, and still the sequence of five is almost twice as fast with an agent as it is with plain RPC. From the theoretical calculation, one could assume that a static agent is the preferable choice even in the case of just two calls. Later in the measurement section, we will see that this is not quite true because of the execution time of the program code, the packing agent and its code, the loading agent’ s byte code on the proxy side, service discovery, and especially DGC actions. All these were omitted in this theoretical approximation for the sake of simplicity. If we try to change the size of parameter and return value data in the equations between 0 bytes and 1 kilobyte, we can see that this does not change much the point where an agent becomes profitable over conventional RPC. theor. RPC With very big parameter values theor. agent (>10kB), the use of an agent is theor. d-agent not as advantageous because bandwidth becomes more dominant factor than the network delay. Instead, if we change the bandwidth of a slow connection to 18000 bytes per second (of rural UMTS), we can see that the performance difference between a static and a dynamic agent decreases because transferring of the agent’ s code is faster now. With very low bandwidths such as 1200 bytes per second (typical GSM data), the dynamic agent becomes slower because code transfer takes so much time, but the static agent is still advantageous. Also much lower network delay (
