On-Demand Delivery of Software in Mobile Environments. Gerd Kortuem, Steve Fickas, Zary Segall. Department of Computer Science. University of Oregon.
On-Demand Delivery of Software in Mobile Environments Gerd Kortuem, Steve Fickas, Zary Segall Department of Computer Science University of Oregon Deschutes Hall Eugene, OR 97403 {kortuem, fickas, zs}@cs.uoregon.edu ABSTRACT In this paper we describe ACHILLES, a system for ondemand delivery of software from stationary servers to mobile clients over wireless network links. ACHILLES supports disconnected operations and employs mechanisms for hiding latency of slow networks. It's main features are a cache replacement policy that uses a simple cost model to determine which software components should be removed from the cache, and a mechanism called resource qualification for checking if resources of a mobile computer are sufficient for the successful execution of applications that are to be loaded. An initial implementation has been evaluated and results showing trade-offs for cache replacement policies are presented. KEYWORDS Software-on-Demand, mobile replacement strategy, cost qualification.
computing, cache model, resource
1. INTRODUCTION On-demand delivery of software has recently become popular in the context of the world-wide-web and programming for the Internet. Instead of installing software permanently on a client machine, on-demand delivery mechanisms load software from a server to the client machine before execution. The most prominent example of this approach is the programming language
This research was supported in part by the National Science Foundation (NSF) under grant number MIP 9403573. The content of the information does not necessarily reflect the position or policy of the NSF or University of Oregon.
Java [7] which in connection with web browsers allows applets to be downloaded over the net. Eventually, so-called Network Computers (NCs) could become a viable alternative for regular Personal Computers. Software-on-demand mechanisms have a number of advantages that make them particularly interesting for mobile computing environments: (1) loading software on-demand is a way to overcome the storage limitations of mobile devices, since not every software application has to be stored locally; (2) it is a way to create zero-maintenance mobile computers that do not require manual software installations or updates; (3) it allows to minimize the complexity and size of the operating system and thus reduces the on-board resources of mobile computers. However, on-demand delivery mechanisms like the ones employed in web browsers are not directly usable in a mobile environment. Current web browsers download an applet every single time it is executed. The underlying assumption is that the browser is connected to a high speed network and thus download times are small. Similarly, it is assumed that a network connection can be established at any time prior to downloading. In a mobile setting both assumptions are no longer true. Not only is the bandwidth of wireless networks lower than the one of wired networks, a mobile computer is also more likely to be disconnected from any network for a significant amount of time. This might be because the user is out of reach of the wireless network or because the costs of using the network are too high (both in terms of money and battery usage1). Because of these reasons current on1
Battery lifetime plays a significant role in the decision whether to use a wireless network or not. Wireless
software-on-demand mechanisms are unsuited for mobile environments.
User Awareness: The presence of a slow wireless network can be masked, but not completely hidden from the user. We want the user to stay informed about important system parameters and have control about when and how to load software. The approach realized in ACHILLES is novel in many respects:
A. Goals and Directions In order to develop an effective software-on-demand mechanism for mobile environments we are employing techniques such as prefetching and caching which have long been used to improve data transfer between computers (for example to mask network latencies and bandwidth limitations). However, with the increasing size of typical software packages more and more valuable storage space of mobile machines is taken up by software as opposed to just data. Thus, the traditional distinction between data (i.e. files) and software does not seem to be justified any more.
First, ACHILLES uses a software cache to control how often and when software is loaded. The use of the software cache allows the user of the mobile device to shutdown the communication link without affecting the functionality of the mobile device. The cache replacement strategy employed in ACHILLES is based on a cost model that incorporates information about the size of applications to load and current network traffic. The result is a reduction in network traffic and download times.
Consequently, in our approach we do not make a fundamental distinction between software and data. Instead, we treat a mobile device as a cache-only architecture where frequently used software and data end up a cache on the mobile device.
Second, ACHILLES introduces the notion of resource qualification, a mechanism that guarantees that applications can successfully be executed on the mobile machine. Resource qualification is performed before applications are loaded; applications that do not qualify, i.e., whose resource needs exceed the resources of the mobile computer, are not loaded. This not only reduces network traffic, it also avoids problems during execution that might occur if an application's resource needs are not fulfilled. Resource qualification is especially useful in a heterogeneous environment with a wide range of mobile devices (PDAs, laptop computers etc.).
In order to test and evaluate our ideas we have designed and implemented an experimental softwareon-demand system called ACHILLES. The main goals and research directions for ACHILLES are: Support for Disconnected Operations: Users should be able to use the mobile device without being permanently connected to a network. Reduction of Network Traffic: This is neccessary to accommodate the unique characteristics of mobile, wireless networks. Language Independence: To support a wide variety of mobile hardware platforms for which Java is not available, we want to be able to download binary code of commercial software applications (COTS). Reduction of maintenance costs: One of the reasons not to move software across networks has long been the notorious difficulty in installing software. We overcome this problem by means of an automatic installation procedure which reduces the need for user intervention.
Third, for communication between server and client ACHILLES uses a protocol which is independent of the underlying transport mechanism. Software can thus be delivered synchronously and asynchronously. This paper is organized as follows. The next chapter gives a description of the ACHILLES system from a user's point of view. Chapter 3 describes the overall system architecture and the mechanism for downloading software on demand. Chapter 4 discusses resource qualification. In Chapter 5 we describe the cache replacement strategy. Experimental results are discussed in Chapter 6. The final chapter discusses future research questions. 2. SOFTWARE ON DEMAND We now give a description of the ACHILLES system from a user's point of view.
modems heavily drain battery power which can force the user to recharge batteries or shutdown the computer sooner.
-2-
Figure 1 shows the user-interface (application browser) of the ACHILLES system as it is used on the mobile computer. The browser is a simple list box that displays all software applications that are available on the server. The user can select and execute individual applications and switch between running applications. Information about applications indicate whether they are stored locally on the mobile device or whether they must be downloaded before execution. The user has the choice between two operation modes: automatic and manual. Automatic Mode: In automatic mode, applications are downloaded from a server if they are not stored locally. This mode is useful if the capacity of the mobile device is not sufficient to store all required applications at once. Assuming the presence of a mobile network, the user has immediate access to a large number of applications limited only by the storage capacity of the server. Manual Mode: Depending on the size of the applications and the bandwidth of the wireless link load times can be significant. In manual mode, the user can specify which applications should be stored on the device permanently and which ones can be unloaded if necessary. Manual mode is useful for prefetching applications. For example, before leaving the office a user could prefetch the applications which he or she will be using in the course of the day. If need should arise, the user can always load additional software. 2
Figure 1: Application Browser Applications to be loaded can either be binary files for immediate execution or source files in an interpreted language. This is in contrast to the approach taken by Java and the Dynamic Documents described by Kaashoek [4]. In both modes, manual and automatic, the system tracks resource dependencies for the user. This allows it to verify a) that an application that is to be downloaded can actually be executed on the device and b) that an application that is to be removed from the cache is not important in the sense that another application depends on it. A good example for the latter case is the relationship between an interpreted program written in Java or Tcl/Tk and the corresponding interpreter. While removing the interpreter might free valuable disk space, it makes it impossible to run the application program. In either case ACHILLES informs the user about these things, but leaves it up to the user to decide which actions to take. The net result is a significant increase of usability.
2
On-demand delivery of software can also be used to load system software like device drivers as side effect of installing additional hardware devices. This aspect is important for our work on wearable computing (see [10]). Wearable computers are body-worn, networked, mobile computers designed for hands-free operation. Wearable computers have a modular system architecture which allows the user to add and remove hardware modules (camera, global positioning system, heat sensor, or other sensory devices) at any time in order to increase the system capabilities. However, most hardware components require special software components (e.g., software drivers, or other system extensions) to function properly. Using our approach, these software components can be loaded and installed automatically as side effect of the installation of hardware modules.
3. SYSTEM ARCHITECTURE In ACHILLES the basic unit for storing and loading software is the application package. Application packages (or packages for short) roughly correspond to Java's applets, but are more powerful. A package is a physical storage unit used for transmitting software over the network. It consists of two parts, a data part which contains data and files that make up a software application, and a directory part which contains -3-
installation instructions and information resource needs of an application.
about
Mobile Computer
Application Browser
The ACHILLES system consists of several components as shown in Figure 2. On the mobile client we have four components: application browser, application cache, loader, and the configuration manager. The application server runs on a stationary computer. We assume that the mobile computer is connected to the application server through a wireless network.
1.
12.
Application Cache 2.
6.
11. 5.
Loader
Application browser: The application browser allows the user to select and execute individual applications (Figure 1). In addition, it provides feedback about the status of the applications cache and of ongoing operations such as loading of an application. Cache Manager: The cache is a non-volatile data structure for storing information about application packages. It does not physically store packages (i.e. files), but package names and directory information that indicates where applications are stored on disk. The cache manager implements the cache replacement strategy, i.e. it determines under which circumstances loaded packages are removed from the cache. At present, only complete packages can be evicted from the cache, but not individual files. The cache replacement strategy is discussed in Chapter 5. Loader: The loader is responsible for loading packages from a server and installing them on the mobile computer. Using installation instructions contained in directory part of packages it extracts individual files from the data part and stores them in appropriate locations on disk3. Configuration Manager: The configuration manager maintains a list of all software applications and hardware devices which are currently installed on the mobile computer. In addition, it maintains dependency information in order to track which software requires which other software or hardware. This information is used for resource qualification as described in Chapter 4.
7.
8. 3.
4. 9.
Configuration Manager
10.
Application Server
Figure 2: System Architecture Application Server. The application server functions as an application repository. It is a file server that persistently stores packages. Loader and application server communicate using a protocol which is independent of the underlying transport mechanism. This allows packages to be delivered using a direct TCP/IP connection, but also through an electronic mail system using protocols like SMTP or POP. In the following we describe how these components interact. Numbers in the text refer to numbers in Figure 2. Initially, a mobile device does not contain any application software, that is the cache is empty. When the user selects an application for execution, the browser sends a look-up request to the cache (1). If the application is present, the cache immediately returns the location of the executable and the browser can execute the application. The more interesting case occurs if the application cannot be found in the cache. This generates an application fault and a request is sent to the loader to load the appropriate package from the server (2). The loader first requests and receives (3,4) the directory part of the package. It passes it on to the configuration manager for resource qualification (5). The configuration manager determines whether the
3
On platforms without a file system (like Apple's Newton) installation could make use of the native installation mechanism.
-4-
Upon request, the name server resolves applications ids into URLs. It does this by maintaining a list of applications servers which it queries regularly.
local resources are sufficient for a successful execution of the application that is to be downloaded. For that purpose, the configuration manager matches resource needs as expressed in the directory part of the package against the current hardware and software configuration of the mobile device. First, it determines if there is enough disk space for installing the application. Second, it determines if all other resource needs can be satisfied, that is, if all required software and hardware is installed (see Chapter 4).
4. RESOURCE QUALIFICATION The configuration manager maintains information about the current software and hardware configuration of the mobile computer. It's main task is resource qualification, that is, to match resource needs of applications against available resources of the mobile machine. Resource qualification is performed before individual applications are loaded with the goal to reject those applications whose resource needs exceed the available resources of the mobile computer.
Depending on the result, one of three events can happen: There is not enough disk space for installing an application: in this case, the configuration manager asks the cache which of the already installed packages can be removed according to the cache replacement strategy (6, 7). The configuration manager passes this information on to the loader (8) which deinstalls the corresponding package or packages. There is enough disk space for installation, but other resources are not sufficient: in this case the configuration manager signals a resource failure to the loader (8). Both disk space and resources are sufficient: the configuration manager signals success to the loader (8). If there are enough resources to store and execute the application, the loader requests the data part of the package from the application server, and - after receiving it - extracts and installs the files (9, 10). After a successful installation it informs the cache manager where the application is stored on disk (11). In case the loader cannot contact the application manager to request either part of a package or a network error occurs during transmission, the loader signals a network failure. Eventually, the cache informs the application browser about success or failure of the entire operation and - if successful passes a pointer to the application for execution (12).
Under the term resource we subsume all system services and components an application depends upon for successful execution. This includes free disk space, installed memory, CPU type, installed I/O devices, remaining battery lifetime, and network availability. In particular, packages are handled as resources as well. This way we can express that one package depends on another package (for example, an application written in an interpreted language like Java or Tcl/Tk depends on the corresponding interpreter which itself is a package). Configuration information is represented as resource dependency graphs. A resource dependency graph is a labeled graph where nodes denote resources and links dependencies between resources. Figure 3 shows an excerpt of a dependency graph as used by the configuration manager. It expresses the fact that one application program called ``Navigator'' directly or indirectly depends on seven other resources, some of them software and some of them hardware resources. Labels (which are not shown in Figure 3) are used to qualify the dependency. For example we can express the fact that an application requires 8MB of memory and 2MB of free disk space. Dependency information is stored and extracted from the directory part of packages. The configuration manager combines dependency information from all installed packages into one system-wide dependency graph. 4
The loader uses the name server to determine the location of applications, i.e. on which server(s) a particular application is stored. Applications are identified by globally unique ids and locations on servers are identified by URLs (e.g. http://www.cs.uoregon.edu/wearable/achilles/package.
4
The dependency graph can also be edited by hand to add default dependencies.
-5-
Tcl/Tk Interpreter
network driver preference file “init.dat”
is not enough disk space for installing a downloaded application. Automatic: The contents of the cache is controlled by the system using a new cache replacement strategy which we call Minimal Cost Strategy (MC). The Minimal Cost strategy uses a cost model in order to determine which software components should be removed from the cache. The cost model incorporates the following criteria: (1) Cost of reloading an application once it has been removed. We are using a simple cost model based on the size of the package and the current available network bandwidth. This results in an approximation for the download time of applications which can be used to rate packages. In general it is preferred to remove applications with a short reload time. (2) Importance of an application. Importance is defined as the number of components that depend on a package. This information can be extracted from the resource dependency graph maintained by the configuration manager; it is equal to the number of incoming dependency links in the transitive closure of the dependency graph. The more applications depend on the application under investigation, the higher is it's importance. Since a package is unusable if not all of the packages it depends on are present, it is preferable to remove applications which are least important.
RAM
“Navigator”
sound DLL
modem card
sound card
Figure 3. Partial Resource Dependency Graph Besides resource qualification, the information contained in the resource dependency graph is used for two other purposes. First, for determining which package should be removed from the cache, if this should become necessary. This is described in more detail in the next chapter. Second, for recursive loading of dependent packages. For this purpose the configuration manager inserts the dependency information of an initial package into the resource graph and determines if there are any packages which are required, but not presently installed. This information is forwarded to the loader which loads the missing packages. By doing this process recursively we can compute and load the transitive closure of a package with regard to the dependency relation. Resource qualification is an important tool both for minimizing network traffic and for ensuring that installed software is compatible with the hardware and software platform. For example, loading Internet phone software onto a mobile device does not make sense if the mobile computer is not equipped with a microphone or speaker. With resource qualification we can detect this conflict before actually downloading the application and thus prevent the system from crashing or misbehaving. Thus, resource qualification is both a means for saving network bandwidth and increasing system reliability.
6. EXPERIMENTAL RESULTS We performed several experiments in order to evaluate the efficiency of the Minimal Cost cache replacement strategy under various conditions. Our main goal was to evaluate the efficiency of the Minimal Cost strategy relative to other cache strategies, notably LRU. A. Experimental Setup The evaluated measures of performance are:
5. CACHE REPLACEMENT POLICIES ACHILLES uses two complimentary cache replacement policies:
•
load time: we measured the time it takes to load a predefined set of software components. energy consumption: we measured the amount of • battery energy that was used for loading a predefined set of software components. These parameters represent the dependent parameters of this experiment. The independent parameters are:
Manual: The user has complete control about the contents of cache, i.e., the user specifies which applications should be removed from the cache. This is realized by presenting the user with a list of currently loaded applications from which the user can select one or more for deletion whenever there -6-
•
• •
Cache Policy (LRU, MC). MC uses a simple cost model in order to determine which component should be removed from the cache in case a cache overflow occurs. The cost of removing a particular component is equal to the time or energy necessary to reload the component. Thus, the cost is proportional to the product of component size and network bandwidth. Cache Size (10MB, 20MB) Bandwidth of network connection to application server. In order to evaluate the effect of varying network bandwidths, tests were run in two ways: First, all components were stored on the same server. This setup effectively removes the network bandwidth component from the above equations so that the cost of removing a particular component is proportional to its size (results of these runs are labeled LRU and MC). Second, components were evenly distributed across two servers A and B with different bandwidth. The relation of the bandwidths of servers A and B were 1:3, that is access to server A was three times slower than to server B (results of these runs are labeled LRU+ and MC+).
(2) given enough time, MC has a clear advantage over LRU. Observation 2: LRU becomes better with increasing cache size / configuration size ratio. Figure 3 shows that LRU outperforms MC for a cache size of 20MB. Observation 3: MC is clearly better than LRU, if the cache is small (relative to average configuration size) or some components have high individual costs (as in the case of MC+). In Figure 4, which compares LRU+ and MC+ (that is software components are stored on two servers with different bandwidth), it is visible how MC+ outperforms LRU+. This is in contrast to the behavior of LRU and MC for the same cache size. Observation 4: Figure 5 shows the performance of LRU, LRU+, MC, and MC+ in terms of power consumption. Given the inaccuracy of the built-in battery gauge of the tested notebook it is surprising that a clear trend is visible. Again LRU is better than MC, but MC+ is better than LRU+. 7. OUTLOOK The research presented in this paper represents work in progress. The ACHILLES system as described is an experimental platform which allows us to investigate alternative solutions to a number of problems. In the future we hope to extend ACHILLES in several directions.
B. Results In order to minimize disturbance due to varying network traffic, each test (that is, each combination of the independent parameters), was run several times. Charts containing measured values for a number of these tests can be found in the Appendix. The numbers in the graphs are cumulative numbers, that is each bar in a graph represents the sum of all numbers ‘to the left’.
First of all, we are planning to continue our evaluation of the Minimal Cost cache replacement strategy. In the future, we hope to make our observations more specific and be able to quantify our results.
Whenever a test was performed several times, measured values for load time and power consumption showed only slight variations due to varying network traffic. However, not enough tests were run to systematically eliminate the effect of varying network traffic. Thus, the reported numbers are preliminary and must be interpreted carefully.
Our work currently assumes that mobile on-demand clients have enough processing power to run applications in their entirety. In the future we are planning to investigate how applications could be broken down into smaller parts so that only a thin client has to be executed on the mobile computer while the remaining parts can run on stationary computers. Solutions along these lines have been proposed under the term application partitioning [3,8,9].
The results we observed can be summarized as follows: Observation 1: For small cache sizes (10MB) MC is clearly better overall than LRU. The graphs shows in Figures 1 and 2 (load times) a clear trend: (1) both MC and LRU are clearly better than NONE
One of the question we hope to answer is the optimal size of such application components. The optimal size depends on the goal one wants to achieve (for example to maximize overall system performance or to -7-
minimize network traffic) and the cache replacement strategy used to determine when application components are removed from the cache.
Mobile Computing Systems and Applications, December 1994.
5. J.J. Kistler. Disconnected Operation in
a Distributed File System. PhD. Thesis, Carnegie Mellon University, May 1993.
Another important direction of our future research are prefetching strategies. ACHILLES currently allows users to manually prefetch applications, but does not use any automatic prefetching mechanism as for example employed in Coda [5,6]. In the future we hope to use the information maintained in the resource dependency graph for developing adaptable prefetching strategy as part of ACHILLES.
6. J.J. Kistler and M Satyanarayanan. Disconnected Operation in the Coda File System. In Proceedings of the Thirteenth ACM Symposium on Operating Systems Principles, Pages 213-225, 1991.
7. Sun
Microsystems, Java White HTTP://www.sunsoft.com/doc.
Finally, we hope to make resource qualification a dynamic process [2,4]. In it's current form, resource qualification is performed once before downloading an application. Mobile environments however are highly dynamic and thus resource availabilities can change at any time. A dynamic mechanism that reevaluates resource needs of loaded applications periodically could be used in connection with application partitioning to load or unload individual components depending on current resource availabilities.
Papers.
8. B. N. Schilit, N.M. Theimer, and B.B. Welch. Customizing Mobile Applications. In Proceedings USENIX Symposium on Mobile & Location-Independent Computing, Pages 129138, August 1993.
9. T. Watson. Application Design for Wireless Computing. In Proceedings of the Workshop on Mobile Computing Systems and Applications, December 1994.
10. Steve Fickas, Gerd Kortuem, Zary Segall.
8. ACKNOWLEDGEMENTS The authors would like to thank Marilynn Livingston for her valuable comments and constructive criticism. Thanks also for Pat Arleth and Christopher Chung for their help with the implementation.
Wearable Computing Web Site, University of Oregon, http//www.cs.uoregon.edu/wearables.
REFERENCES 1. F. Bennet, Richardson T., and A Harter. Teleporting Mobile Applications. In Proceedings of the Workshop on Mobile Computing Systems and Applications, December 1994.
2. T Fallmyr. Adaptable Mobile Systems. In IEEE Workshop on Future Trends in Distributed Computing, August 1995.
3. D. Goldberg and M Tso. How to Program Networked Portable Computers. In Proceedings of the 4th Workshop on Workstation Operating Systems (WWOS-IV), October 1993.
4. M. F. Kaashoeck, T. Pinckney, and J. A. Tauber. Dynamic Documents: Mobile Wireless Access to the WWW. In Proceedings of the Workshop on -8-
APPENDIX Cache Performance (10MB) 3000000
2500000
Time [ms]
2000000
NONE (SUM) LRU (SUM) MC (SUM)
1500000
1000000
500000
conf4
conf7
conf9
conf4
conf7
conf9
conf6
conf1
conf5
conf4
conf1
conf10
conf10
conf2
conf7
conf9
0
Configuration #
Figure 1.
Cache Performance 10MB 6000000
5000000
MC+ (SUM) LRU+ (SUM)
3000000
2000000
1000000
Configuration #
Figure 2.
-9-
conf4
conf7
conf9
conf4
conf7
conf9
conf6
conf1
conf5
conf4
conf1
conf10
conf10
conf2
conf7
0 conf9
Time [ms]
4000000
Cache Performance (20MB) 6000000
5000000
Time [ms]
4000000
NONE (SUM) LRU (SUM) MC (SUM)
3000000
2000000
1000000
conf4
conf7
conf9
conf4
conf7
conf9
conf6
conf1
conf5
conf4
conf1
conf10
conf10
conf2
conf7
conf9
0
Configuration #
Figure 3.
Cache Performance (20MB) 4500000
4000000
3500000
2500000 MC+ (SUM) LRU+ (SUM) 2000000
1500000
1000000
500000
Configuration #
Figure 4.
-10-
conf4
conf7
conf9
conf4
conf7
conf9
conf6
conf1
conf5
conf4
conf1
conf10
conf10
conf2
conf7
0 conf9
Time [ms]
3000000
Change in Battery Level 9000
8000
7000
6000
5000
4000
3000
2000
1000
0 conf9 conf2 conf7 conf9 conf2 conf7 conf10 conf2 conf10 conf6 conf1 conf3
Battery Usage (20MB)
conf4 Configuration #
-11-
Figure 5.
conf10 conf5 conf8 conf1 conf5 conf6 conf8 conf9 conf2 conf7 conf3 conf4 conf10 conf9 conf2 conf7 conf3 conf4 LRU MC LRU+ MC+
