client-server computing in mobile environments · 2015-06-16 · client-server computing in mobile...

Client-Server Computing in Mobile EnvironmentsJIN JING

GTE Laboratories Incorporated

ABDELSALAM (SUMI) HELAL

University of Florida

AND

AHMED ELMAGARMID

Purdue University

Recent advances in wireless data networking and portable information applianceshave engendered a new paradigm of computing, called mobile computing, in whichusers carrying portable devices have access to data and information servicesregardless of their physical location or movement behavior. In the meantime,research addressing information access in mobile environments has proliferated. Inthis survey, we provide a concrete framework and categorization of the variousways of supporting mobile client-server computing for information access. Weexamine characteristics of mobility that distinguish mobile client-server computingfrom its traditional counterpart. We provide a comprehensive analysis of newparadigms and enabler concepts for mobile client-server computing, includingmobile-aware adaptation, extended client-server model, and mobile data access. Acomparative and detailed review of major research prototypes for mobileinformation access is also presented.

Categories and Subject Descriptors: C.2.4 [Computer-CommunicationNetworks]: Distributed Systems

General Terms: Algorithms, Design

Additional Key Words and Phrases: Application adaptation, cache invalidation,caching, client/server, data dissemination, disconnected operation, mobileapplications, mobile client/server, mobile computing, mobile data, mobilityawareness, survey, system adaptation

1. INTRODUCTION

Advances in wireless networking tech-nology and portable information appli-ances have engendered a new paradigm

of computing, called mobile computing,in which users who carry portable de-vices have access to information ser-vices through a shared infrastructure,

Authors’ addresses: J. Jing, GTE Laboratories Incorporated, 40 Sylvan Road, Waltham, MA 02454; A.Helal, Computer and Information Science and Engineering Department, University of Florida, Gaines-ville, FL 32611; email: [email protected]; A. Elmagarmid, Computer Sciences, Purdue University, WestLafayette, IN 47907.Permission to make digital / hard copy of part or all of this work for personal or classroom use is grantedwithout fee provided that the copies are not made or distributed for profit or commercial advantage, thecopyright notice, the title of the publication, and its date appear, and notice is given that copying is bypermission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute tolists, requires prior specific permission and / or a fee.© 1999 ACM 0360-0300/99/0600–0117 $5.00

ACM Computing Surveys, Vol. 31, No. 2, June 1999

regardless of their physical location ormovement behavior. Such a new envi-ronment introduces new technical chal-lenges in the area of information access.Traditional techniques for informationaccess are based on the assumptionsthat the location of hosts in distributedsystems does not change and the con-nection among hosts also does notchange during the computation. In amobile environment, however, these as-sumptions are rarely valid or appropri-ate.

Mobile computing is distinguishedfrom classical, fixed-connection comput-ing due to (1) the mobility of nomadicusers and their computers and (2) themobile resource constraints such as lim-ited wireless bandwidth and limitedbattery life. The mobility of nomadicusers implies that the users might con-nect from different access pointsthrough wireless links and might wantto stay connected while on the move,despite possible intermittent disconnec-tion. Wireless links are relatively unre-liable and currently are two to threeorders of magnitude slower than wire-line networks. Moreover, mobile hostspowered by batteries suffer from limitedbattery life constraints. These limita-tions and constraints leave much workto be done before mobile computing is

fully enabled. This remains true despitethe recent advances in wireless datacommunication networks and hand-helddevice technologies.

There has been a recent proliferationof research addressing issues of mobilesystems and applications, especially forthe purpose of mobile information ac-cess. In this survey, we attempt to pro-vide a concrete framework and categori-zation of various methods of supportingsuch applications and information ac-cess from the viewpoint of client-servercomputing. The scope of this survey cov-ers techniques and methods in supportof components above the transport layerof networks. In a mobile client-serverinformation system, a loose or tight col-lection of trusted information serversare connected via a fixed network toprovide information services to a muchlarger collection of untrusted mobile cli-ents over wireless and mobile networks.

1.1 Paradigms of Mobile Client-ServerComputing

In this section, we briefly examine theimpacts of mobility on information ser-vices and applications, and the new par-adigms of client-server computingneeded to deal with these impacts. Acategorization of these computing para-digms is given below. This examinationshould facilitate our analysis and re-view of the various proposed techniquesfor mobile information access.

Existing research on mobile client-server computing can be categorizedinto the following three paradigms: (1)mobile-aware adaptation, (2) extendedclient-server model, and (3) mobile dataaccess.

Mobile-aware Adaptation: The dy-namics of mobile environments and thelimitations of mobile computing re-sources make adaptation a necessarytechnique when building mobile sys-tems and applications. The paradigm ofmobile-aware adaptation covers variousstrategies and techniques in how sys-tems and applications respond to theenvironmental changes and the re-

CONTENTS

1. Introduction1.1 Paradigms of Mobile Client-Server Computing1.2 Organization of this Paper

2. Mobile-Aware Adaptation2.1 Application-Transparent Adaptation2.2 Application-Aware Adaptation

3. Extended Client-Server Model3.1 Thin Client Architecture3.2 Full Client Architecture3.3 Flexible Client-Server Architecture

4. Mobile Data Access4.1 Server Data Dissemination4.2 Client Cache Management

5. Case Studies5.1 Bayou5.2 Odyssey5.3 Rover5.4 Summary

6. Conclusion

118 • J. Jing et al.


source requirements. It also suggeststhe necessary system services thatcould be utilized by mobile-aware appli-cations.

Extended Client-Server Model: Theextended client-server model facilitatesmobile client-server information access.One distinguishing feature is the dy-namic partitioning of client-server func-tionality and responsibilities. The ex-tended client-server model provides away to support the adaptation of mobilesystems and applications. The paradigmof the extended client-server model in-cludes various client-server computingarchitectures that enable the functionalpartitioning of applications between cli-ents and servers.

Mobile Data Access: Mobile data ac-cess addresses issues such as howserver data can be delivered to clienthosts, how data over wireless and mo-bile networks is structured, and how theconsistency of client cache is ensuredeffectively. The adaptive strategies formobile data access depend largely onthe type of communication links, theconnectivity of mobile hosts, and theconsistency requirements of applica-tions. In our view, mobile data accessprovides another way to characterizethe impact of mobile computing con-straints on information access.

It should be noted that these newparadigms are closely related to eachother. For example, the implementationfor data delivery strategies and ex-tended client-server architectures mayinvolve the use of adaptation solutions.Extended client-server architecturesmight be needed to take advantage ofnew data delivery strategies. The cate-gorization of new paradigms in this sur-vey paper provides a comprehensiveway to understand and analyze variousproposed techniques in building mobileclient-server information systems.

1.2 Organization of this Paper

The remainder of this paper is orga-nized as follows. In Section 2, we dis-cuss the paradigm of mobile client-

server computing, namely, mobile-aware adaptation. The emphasis in thissection is on understanding how adap-tation strategies can be built into sys-tem and application components. InSection 3, we describe how the client-server model has been extended toadapt to the dynamic environments. InSection 4, we examine proposed tech-niques for mobile data access, includingserver data dissemination and clientcache management. Finally, Section 5reviews and analyzes three researchprototypes of mobile client-server infor-mation systems, namely, Bayou, Odys-sey, and Rover. Concluding remarks areoffered in Section 6.

2. MOBILE-AWARE ADAPTATION

Mobile clients could face wide varia-tions and rapid changes in network con-ditions and local resource availabilitywhen accessing remote data. In order toenable applications and systems to con-tinue to operate in such dynamic envi-ronments, the mobile client-server sys-tem must react by dynamicallyadjusting the functionality of computa-tion between the mobile and stationaryhosts. In other words, the computationof clients and servers has to be adaptivein response to the changes in mobileenvironments [Katz 1994].

In Satyanarayanan [1996], the rangeof strategies for application and systemadaptation is identified, as shown inFigure 1. The range is delimited by twoextremes. At one extreme, adaptation isentirely the responsibility of individualapplications. This approach, calledlaisse-faire adaptation, avoids the needfor system support. The other extreme,called application-transparent adapta-tion, places the entire responsibility foradaptation on the system. A typical caseof this approach is to use proxies toperform adaptation on behalf of applica-tions. Between these two extremes liesa spectrum of possibilities that are re-ferred to as application-aware adapta-tion. This approach supports collabora-tive adaptation between the

Client-Server Computing in Mobile Environments • 119


applications and the system. That is,the applications can decide how to bestadapt to the changing environmentwhile the system provides supportthrough the monitoring of resources andthe enforcing of resource allocation deci-sions. This section will discuss differentproposed adaptation approaches.

2.1 Application-Transparent Adaptation

Many existing client-server applicationsare built around the assumption thatthe environment of a client does notchange. These applications are usuallyunaware of the mobility and make cer-tain assumptions about the resourceavailability. The approach of applica-tion-transparent adaptation attempts tomake these applications work with nomodification in mobile environments.This is done by having the systemshield or hide the differences betweenthe stationary and mobile environmentsfrom applications. Examples of this ap-proach include Coda [Satyanarayananet al. 1990; Kistler and Satyanarayanan1992], Little Work [Honeyman et al.1992], and WebExpress [Housel andLindquist 1996; Chang et al. 1997]. Inthese examples, a local proxy runs onthe mobile host and provides an inter-face for regular server services to theapplications. The proxy attempts to mit-igate any adverse effects of mobile envi-ronments.

2.1.1 File System Proxy. The basicidea is to use a file system proxy to hidemobile issues from applications and toemulate file server services on the mo-

bile computers (see Figure 2). The Codafile system [Kistler and Satyanaray-anan 1992], pioneering this approach,uses a file system proxy to make exist-ing applications work with no modifica-tion. The proxy logs all updates to thefile system during disconnection and re-plays the log on reconnection. Auto-matic mechanisms for conflict resolu-tion using optimistic concurrencycontrol are provided for directories andfiles through the proxy and the fileserver. The file system proxy in Codafacilitates the following features:

Disconnected Operations: A small col-lection of trusted Coda servers exports alocation-transparent UNIX file namespace to a larger collection of untrustedclients. On each client, a user-level pro-cess, Venus, manages a file cache on thelocal disk. Venus acts as a file systemproxy and bears the brunt of discon-nected operations. Venus operates inone of three states: hoarding, emulat-ing, and reintegrating. In the hoardingstate, server files are pre-fetched ontothe mobile computer. Upon disconnec-tion, Venus enters the emulating stateand begins logging updates in a clientmodify log. In this state, Venus per-forms log optimizations to improve per-formance and reduce resource usage.Upon reconnection, Venus enters the re-integrating state, where it synchronizesits cache with the servers, propagatesupdates from the client modify log, andreturns to the hoarding state.

In anticipation of disconnection, usersmay hoard data in the cache by provid-ing a prioritized list of files in a per-

Laissez faire(No system support)

Application-transparent(No changes to applications)

Application-awareness(collaboration)

Figure 1. Range of adaptation strategies.



client hoard database. Venus combinesthe hoard database information withLRU (Least Recently Updated) informa-tion to implement a cache managementpolicy. Periodically, Venus walks thecache to ensure that the highest priorityitems are present and consistent withthe servers. A user may also explicitlyrequest a hoard walk at any time. Sinceconsistency is based on optimistic rep-lica control, update conflicts may occurupon reintegration. The system ensuresthe detection and confinement of updateconflicts and provides mechanisms tohelp the users recover from them.

Weakly Connected Operations: Thefile system proxy pre-fetches serverdata into the client cache and uses ob-ject or volume1 callbacks for the cachevalidation in order to support weak con-nectivity. Volume call back is pessimis-tic in that invalidating a volume invali-dates all the objects in this volume.However, the gain is in reducing cacheinvalidation information that needs tobe communicated between the clientand the server. The file system proxycan determine, based on factors such ascached data structures and connectivitychanges, whether object or volume call-backs are best for a particular connec-tion. The variable granularity of call-back attempts to minimize the cost ofvalidation and invalidation to provide

effective support of operations forweakly connected clients.

Isolation-only Transactions: Discon-nected operations may result in datainconsistency due to conflicting opera-tions on multiple disconnected comput-ers. Isolation-only Transaction (IOT) isproposed to automatically detect read/write conflicts. The execution of IOT isrealized by the file system proxy code inthe Coda system. An IOT provides con-sistency guarantees depending on thesystem connectivity conditions. Unliketraditional transactions, it does notguarantee failure atomicity and onlyconditionally guarantees permanence.

When an IOT is completed, it enterseither the committed or the pendingstate, depending on the connectivitycondition (see Figure 3). If the executionof an IOT does not contain any parti-tioned file access, it is committed andits result is made visible on the servers.Otherwise, it enters the pending statefor later validation. The result is tempo-rarily held within the client’s localcache and is visible only to subsequentprocesses on the same client. When therelevant partitions are repaired, theIOT is validated according to the isola-tion consistency criteria, namely, serial-izability. If the validation succeeds, theresult will be immediately reintegratedand committed to the servers. Other-wise, the IOT enters the resolutionstate. When it is automatically or man-1A volume is a collection of related objects.

Fixed NetworkMobile Host

File Server

Mobile

File System Proxy

Applications

Mobile File System APIs

File

System

APIs

Figure 2. File system proxy.



ually resolved, it will commit the newresult to the server.

In addition to the Coda project, otherprojects address similar adaptation is-sues for mobile file system applications.In the Rover project, a file system proxyis added to the Rover Toolkit’s object-based model [Joseph et al. 1996; 1997].It allows the Rover Toolkit to supportboth a file model and an object modelfor mobile applications. The file systemproxy in Rover Toolkits also addresses anumber of issues related to file caching,prefetching, and conflict detection andresolution. These issues are similar tothose addressed by the Coda file sys-tem, except that they are associatedwith integrating a file system modelwith an object-based model. The Roverfile system proxy consists of two compo-nents: a user-level installable local filesystem proxy located on the client and aremote file system proxy running on aRover server. The two components worktogether with the use of Rover’s queuedcommunication mechanism that sup-ports automatic message compressionand batching. The Ficus file system isanother file system supporting discon-nected operations with application-transparent adaptation, but relies onversion vectors to detect conflicts [Hei-demann et al. 1992]. The Little Workproject caches files for smooth discon-nection from an AFS file system [Hon-

eyman et al. 1992]. Conflicts are de-tected and reported to the user formanual resolution.

2.1.2 Web Proxy. Web proxy enablesWeb browsing applications to functionover wireless links without imposingchanges on browsers and servers. Webproxy can be used to prefetch and cacheWeb pages to the mobile client’s ma-chine, to compress and transform imagepages for transmission over low-band-width links, and to support discon-nected and asynchronous browsing op-erations.

WebExpress [Housel and Lindquist1996] uses this approach to interceptand control communications over thewireless link for the purposes of reduc-ing traffic volume and optimizing thecommunication protocol to reduce la-tency. Two components are inserted intothe data path between the Web clientand the Web server: the Client SideIntercept (CSI) process that runs in theclient mobile device and the Server SideIntercept (SSI) process that runs withinthe wired and fixed network (see Figure4).

The CSI intercepts HTTP requestsand, together with the SSI, performsoptimizations to reduce bandwidth con-sumption and transmission latency overthe wireless link. From the viewpoint ofthe browser, the CSI appears as a local

user invocation Committed

file accesses

without partitioned

& reintegration

validation succeed

Resolution

validation fail

Pendingfile accesses

with partitioned

Running

Figure 3. A state transition diagram for IOT execution.



Web proxy that is co-resident with theWeb browser. On the mobile host, theCSI communicates with the Webbrowser over a local TCP connection(using the TCP/IP “loopback” feature)via the HTTP protocol. Therefore, noexternal communication occurs over theTCP/IP connection between the browserand the CSI. No changes to the browserare required other than specifying the(local) IP address of the CSI as thebrowser’s proxy address. The CSI com-municates with an SSI process over aTCP connection using a reduced versionof the HTTP protocol. The SSI reconsti-tutes the HTML data stream and for-wards it to the designated CSI Webserver (or proxy server). Likewise, forresponses returned by a Web server (ora proxy server), the CSI reconstitutesan HTML data stream received from theSSI and sends it to the Web browserover the local TCP connection as thoughit came directly from the Web server.

The proxy approach implemented inWebExpress offers the transparency ad-vantage to both Web browsers and Webservers (or proxy servers) and, there-fore, can be employed with any Webbrowser. The CSI/SSI protocols facili-tate highly effective data reduction andprotocol optimization without limitingany of the Web browser functionality orinteroperability. WebExpress optimiza-tion methods are summarized below:

Caching: Both the CSI and SSI cachegraphics and HTML objects. If the URLspecifies an object that has been storedin the CSI’s cache, it is returned imme-diately as the response. The cachingfunctions guarantee cache integritywithin a client-specified time interval.The SSI cache is populated by responsesfrom the requested Web servers. If arequested URL received from a CSI iscached in the SSI, it is returned as theresponse to the request.

Differencing: CSI requests might re-sult in responses that normally vary formultiple requests to the same URL(e.g., a stock quote server). The conceptof differencing is to cache a commonbase object on both the CSI and SSI.When a response is received, the SSIcomputes the difference between thebase object and the response and thensends the difference to the CSI. The CSIthen merges the difference with its baseform to create the browser response.This same technique is used to deter-mine the difference between HTML doc-uments.

Protocol reduction: Each CSI connectsto its SSI with a single TCP/IP connec-tion. All requests are routed over thisconnection to avoid the costly connec-tion establishment overhead. Requestsand responses are multiplexed over theconnection.

Fixed NetworkMobile Hosts

TCP/IP Connection

(or Proxy Server)

Web Server

Side Intercept (SSI)

Web Express ServerSide Intercept (CSI)

Web Express Client

(TCP/IP)HTTP(TCP/IP)

HTTP

Web Browser

Figure 4. The WebExpress intercept model.



Header reduction: The HTTP protocolis stateless, requiring that each requestcontain the browser’s capabilities. For agiven browser, this information is thesame for all requests. When the CSIestablishes a connection with its SSI, itsends its capabilities only on the firstrequest. This information is maintainedby the SSI for the duration of the con-nection. The SSI includes the capabili-ties as part of the HTTP request that itforwards to the target server (in thewire line network).

The Mowgli project [Kojo et al. 1994]also uses a similar approach to supportWeb applications over wireless links(see Figure 5). A specialized HTTPagent and a specialized HTTP proxy areapplied to: (1) reduce unnecessary mes-sage exchange, (2) reduce the volume ofdata transmitted over the wireless link,and (3) support disconnected opera-tions. The HTTP agent acts as a localWeb proxy on mobile client hosts whilethe HTTP proxy is located in the fixednetwork. With the agent-proxy ap-proach, neither Web clients nor serversneed to be modified. The HTTP agentintercepts requests generated by theWeb client on the mobile node. It com-municates with the HTTP proxy in thefixed network. Both the agent and theproxy maintain a cache of their own toimprove performance over low-band-width links.

2.2 Application-Aware Adaptation

The approach of application-transpar-ent adaptation does not require chang-

ing existing applications to run in mo-bile environments. However, it couldsacrifice functionality and performance.As applications are shielded from deal-ing with mobility, it might be very hardfor the system to make adaptation deci-sions that meet the needs of differentand diverse applications. As a result, itmay have to require some manual inter-vention by the user (e.g., having theuser indicate which data to pre-fetchonto the mobile device) to make applica-tions run smoothly. Such user-adminis-tered manual actions could be less agileto adapt to the changing environment.To address these problems, application-aware adaptation has been developed.

Application-aware adaptation allowsapplications or their extensions to reactto the mobile resource changes. Oneway to realize the application-aware ad-aptation is through the collaboration be-tween the system and individual appli-cations. The system monitors resourcelevels, notifies applications of relevantchanges, and enforces resource alloca-tion decisions. Each application inde-pendently decides how best to adaptwhen notified. In a video player applica-tion, for example, such adaptation al-lows the video player system to scaleback quality (and resource consump-tion) when application performance ispoor and to attempt to discover addi-tional resources by optimistically scal-ing up usage.

Depending on where the adaptive ap-plication logic resides, the approaches ofapplication-aware adaptation can be di-

WWWClient

Mowgli Socket

Mowgli

MDCS

WirelessInterface

HTTPAgent

WWW

WirelessInterface

NetworkInterfaceInterface

Virtual

Mobile IP

TCP / UDP

Socket

HTTPMowgli

Proxy

Server

Socket

TCP / UDP

IP

Network Interface

Fixed HostMobile-Connection Host

Mobil e Node

... ...

Fixed Net

MDCS

Figure 5. The Mowgli wireless Web browsing architecture.



vided into the following categories: cli-ent-based application adaptation, client-server application adaptation, andproxy-based application adaptation. Theclient-based adaptation allows the ap-plications on mobile clients to react tothe environmental changes, while cli-ent-server adaptation might have appli-cations on both client and server toadapt to the changes. The proxy-basedadaptation supports application-specificadaptation on the proxy server in thefixed networks. The application-specificproxies have been used as an intermedi-ary between existing servers and heter-ogeneous mobile clients [Brooks et al.1996; Brewer et al. 1998]. The proxiescan perform aggressive computationand storage on behalf of mobile clients.These approaches can be complemen-tary for a client-server information sys-tem. For example, both client-based andproxy-based adaptation can be used to-gether in a single system to deal withthe mobility.

2.2.1 Client-Based Application Adap-tation. The Odyssey project [Noble etal. 1997] demonstrates a client-basedcollaborative adaptation approach forapplications on mobile clients. In thecollaborative adaptation, the systemprovides the mechanisms of adaptation,while the applications are free to specifyadaptation policy. The division of re-sponsibility addresses the issues of ap-plication diversity and concurrency. In amobile information system, applicationdata can be diverse in terms of dataformats and consistency requirements.For example, the application data maybe stored in one or more general-pur-pose repositories such as file servers,SQL servers, or Web servers. Alterna-tively, it may be stored in more special-ized repositories such as video libraries,query-by-image-content databases, orback ends of geographical informationsystems. The application data can alsohave different dimensions for the speci-fication and representation. For exam-ple, video data can have at least twospecification dimensions: frame rate

and image quality of individual frames.Spatial data, such as topographicalmaps, has dimensions of minimum fea-ture size and resolution. Furthermore,concurrent applications can be very use-ful for mobile users. For example, aninformation filtering application mayrun in the background monitoring datasuch as stock prices and alert the useras appropriate. The collaborative adap-tation accommodates the application di-versity by allowing applications to de-termine how application data presentedat a client matches the reference copy atthe server based on resource levels. Italso supports the application concur-rency by allowing the system to retaincontrol of resource monitoring and arbi-tration.

The application-aware adaptation inOdyssey is performed through the use oftype-specific operations between thesystem and applications. The type-awareness is incorporated into both thesystem for efficient resource usage andthe applications for differential han-dling of data types. The system-levelknowledge of data types facilitates theoptimization of the resource usage fordifferent and diverse applications. Forexample, the size distribution and con-sistency requirements of data from anNFS server differ substantially fromthose of relational database records. Im-age data may be highly compressibleusing one algorithm, but not another.Video data can be efficiently shippedusing a streaming protocol that dropsrather than retransmits lost data; incontrast, only reliable transmissions areacceptable for file or database updates.

Odyssey incorporates type-awarenessvia specialized code components calledwardens. A warden encapsulates thesystem-level support at a client to effec-tively manage a data type. To fully sup-port a new data type, an appropriatewarden has to be written and incorpo-rated into Odyssey at each client. Thewardens are subordinate to a type-inde-pendent component called the viceroy,which is responsible for centralized re-source management. The collaborative



relationship in the application-awareadaptation is thus realized in two parts.The first, between the viceroy and itswardens, is data-centric: it defines theconsistency levels for each data typeand factors them into resource manage-ment. The second, between applicationsand Odyssey, is action-centric: it pro-vides applications with control over theselection of consistency levels supportedby the wardens.

A number of similar approaches havealso been discussed in the literature. Inthe Prayer system [Bharghavan andGupta 1997], the application-aware ad-aptation is supported with the use ofabstractions: QoS classes and adapta-tion blocks. A QoS class is defined byspecifying the upper and lower boundsfor resources. An application divides itsexecution into adaptation blocks. An ad-aptation block consists of a set of alter-native sequences of execution, each as-sociated with a QoS class. At thebeginning of an adaptation block, anapplication specifies the QoS classesthat it is prepared to handle, along witha segment of code associated with eachclass and an action to take should theQoS class be violated within the codesegment.

In Welling and Badrinath [1998], ap-plication-aware adaptation is imple-mented under an event delivery frame-work. In the framework, a notificationsubsystem, called event channel, deliv-ers different events that are generatedby the environment monitor to applica-tions based on delivery policies. For ex-ample, a low memory event may be de-livered to each application in seriesuntil enough memory is freed for otheruses, while a low bandwidth event canbe delivered to each application in par-allel. The applications are notified ofthe events to react to the environmentalchanges.

2.2.2 Client-Server Application Adap-tation. The Rover Toolkit [Joseph etal. 1996; 1997] supports the application-aware adaptation through the use ofrelocatable dynamic object (RDO). The

key task of the programmer when im-plementing an application-specific ad-aptation with Rover is to define RDOsfor the data types manipulated by theapplication and for the data transportedbetween the client and the server. Theprogrammer divides the program thatcontains the RDOs into portions thatrun on the client and portions that runon the server; these parts communicateby means of queuing RPC. The pro-grammer also defines the methods thatupdate objects, including code for con-flict detection and resolution.

At the level of RDO design, applica-tion designers have semantic knowledgethat is very useful in implementing ap-plication-aware adaptation. By tightlycoupling data with program code, appli-cations can manage resource utilizationmore carefully than possible with a clas-sic file or object system that handlesonly generic data. For example, an RDOcan include compression and decom-pression methods along with com-pressed data in order to obtain applica-tion-specific and situation-specificcompression, reducing both networkand storage utilization. The RDO ap-proach provides a generic framework toimplement type-specific or application-specific operations for application-aware adaptation.

The application that consists of theseRDO modules actively cooperates withthe runtime system of the Rover Toolkitto import RDOs onto the local machine,invoke well-defined methods on thoseobjects, export logs of method invoca-tions on RDOs to servers, and reconcilethe client’s copies of the objects with theserver’s.

In Davis et al. [1998], a tuple spacebased platform, called L2imbo, is pro-posed to support mobile distributed ap-plications and adaptation. The platformoffers an asynchronous programmingmodel and architecture for reportingand propagating QoS information aboutmobile environments. The L2imbo ar-chitecture supports mechanisms of ad-aptation with the use of system and



application agents that interact withthe tuple space.

2.2.3 Proxy-Based Application Adap-tation. The application-specific proxyhas been proposed as an intermediarybetween clients and servers to performcomputation intensive and storage in-tensive tasks, such as data type specificlossy compression, on behalf of clients[Brooks et al. 1996; Brewer et al. 1998;Zenel and Duchamp 1997]. This proxyarchitecture reduces the bandwidth de-mands on the infrastructure throughlossy compression and allows legacy andother nonstandard (including thin) cli-ents to inter-operate with existing serv-ers. The proxy-based application adap-tation allows the proxy agents to reactto the environmental changes on behalfof mobile clients. This approach avoidsinserting adaptation machinery at eachorigin server. From the client’s perspec-tive, the proxy is simply a server thatgets the data from someplace else.

In the BARWAN project [Brewer etal. 1998], the application specific proxyuses the transcoders (i.e., proxy agents)

to optimize the quality of service for theclient in real time (see Figure 6). To usetranscoding to adapt to network varia-tion, the proxy must have an estimate ofthe current network conditions alongthe path from the proxy to the client.SPAND (Shared Passive Network Per-formance Discovery), a network mea-surement system, allows a measure-ment host to collect the actualapplication-to-application network per-formance (e.g., available bandwidth andlatency) between proxies and clients.SPAND monitors end-to-end bandwidthand connectivity to the clients (andservers) and notifies the proxy of anychanges, which may result in changes intranscoding to adjust the quality of ser-vice. The original servers are unawareof the transformations or of the limitedcapabilities of the clients or networks.

Compact HTML [CompactHTML 1998]is a W3C submission of a standard forsmall information appliances. It definesa subset of HTML for small informationappliances, such as smart phones, smartcommunicators, and mobile PDAs. The

App Support

Client app

App Support

Client app

Video

Server

Proxy

SPAND

Transcoders

Image

PostScript

Audio

bandwidthMedium

bandwidthHigh

Lowbandwidth

Figure 6. A proxy-based adaptation architecture.



standard is intended as guidelines formanufacturers of small information de-vices, service providers, carriers, and soft-ware developers. Another similar lan-guage (which is relatively less compliantto the W3C HTML recommendation) isthe Hand-held Device Markup Language(HDML) [HDML 1997]. The HDML stan-dard has been adapted into the WirelessMarkup Language (WML), which makesup the application and presentation lay-ers of the Wireless Application Protocol(WAP) stack, whose specification is beingdeveloped by the WAP forum [WAP1996], as a de facto standard. WAP usesWML and provides third party proxies(via a session-layer protocol) as a meansto negotiate device capabilities in terms ofcontent characteristics. The WAP archi-tecture is shown in Figure 7. The WAPproxies are capable of adapting to themobile devices by negotiating and filter-ing the HTML Web content. Filtering isperformed as a translation to and from acompact subset of the HTML language.The filtering process itself can be pre-scribed or automated, based on capabilitynegotiation.

3. EXTENDED CLIENT-SERVER MODEL

Another way to characterize the client-server computing in mobile environ-ments is to examine the effect of mobil-ity on the client-server computingmodel. In a client-server informationsystem, a server is any machine thatholds a complete copy of one or moredatabases. A client is able to access dataresiding on any server with which it cancommunicate. Classic client-server sys-tems assume that the location of clientand server hosts does not change andthe connection among them also doesnot change. As a result, the functional-ity between client and server is stati-cally partitioned. In a mobile environ-ment, however, the distinction betweenclients and servers may have to be tem-porarily blurred [Satyanarayanan1996], resulting in an extended client-server model shown in Figure 8. Theresource limitations of clients may re-quire certain operations normally per-formed on clients to be performed onresource-rich servers. Conversely, theneed to cope with uncertain connectivityrequires clients to sometimes emulate

WAPProxy

Filter

WebServer

FilterWAP Proxy

BinaryWML

WML

WML

BinaryWML

WirelessNetwork

HTML

WTAServer

BinaryWML

HTML

Defined by WAPAP

Not defined by WAPAP

Figure 7. The WAP architecture.



the functions of a server. An extremecase is called the thin client architecturethat offloads most application logic andfunctionality from clients to stationaryservers. In the thin client architecture,applications in stationary servers areusually mobile-aware and optimized formobile client devices. The thin clientarchitecture is especially suitable fordumb terminal or small PDA applica-tions. The other extreme case is the fullclient architecture. The full client archi-tecture emulates server functions on theclient devices and, therefore, is able tominimize the uncertainty of connectiv-ity and communications.

3.1 Thin Client Architecture

The InfoPad project [Le et al. 1994]demonstrates the approach of thin cli-ent architecture. The InfoPad system iscomposed of four layers shown in Figure9: Pad, InfoNet, Type Servers, and Ap-plications. The Pad is a low power, por-table multimedia terminal that is capa-ble of displaying text and graphics,playing audio and compressed video, re-cording audio, and capturing pen input.

The InfoNet layer presents the soft-ware layer above the Pad with an ab-straction in which each pad appears asa stationary, network-connected, multi-media terminal. This layer contains therouting algorithms to make mobilityseamless and the routines to managethe wireless network resources (e.g., al-location of frequencies to pads).

The type servers make the pad appearas a typical workstation to applications;this allows for compatibility with stan-

dard workstation software. The typeservers shield applications from knowl-edge of the mobile environments andterminal hardware. However, applica-tions are optimized for use on the pad.The optimization takes advantage of thespecial characteristics of the pad, suchas small screen size, lack of a keyboard,and support for handwriting and speechrecognition.

While applications in the InfoPad sys-tem are customized for the characteris-tics of the pad, they do not contain codethat allows them to dynamically adaptto changes in mobile networks. Instead,mobile-aware adaptation is largely per-formed in the InfoNet and type serverlayers. In this sense, the adaptation inthe InfoPad system can be characterizedas application-transparent adaptationrather than application-aware adapta-tion.

The thin client architecture from CIT-RIX Corporation allows a variety of re-mote computers, regardless of their plat-form, to connect to a Windows NTterminal server to remotely access a pow-erful desktop and its applications [CIT-RIX 1998]. A server called MetaFrameruns under Windows NT in the desktopmachine and communicates with the thinclients executing at the remote computersusing the Independent Computing Archi-tecture protocol (ICA). The ICA client andthe MetaFrame server collaborate to dis-play the virtual desktop on the remotecomputer screen. They also collaborate toprocess mouse and keyboard events, andto execute programs and view data storedat the server. All executions are remoteand none takes place at the client porta-ble computer. A research project at Mo-torola [Duran and Laubach 1999] ex-tended CITRIX’s thin client architectureso that it is optimized in the wirelessenvironment. The work pointed out thatbandwidth limitation is not as detrimen-tal to the thin client performance as net-work latency. This is because the thinclients’ use of bandwidth is limited.

W4 [Bartlett 1994] applies the tech-nique of dividing application functional-ity between a small PDA and a power-

Fixed Network

Mobile Host

ClientCode

CodeCode Server

Server

CodeClient

Figure 8. Extended client-server model.



ful, stationary host for Web browsing.Other thin client examples include theTop Gun Wingman and Top Gun Media-Board applications in the BARWANproject [Brewer et al. 1998].

3.2 Full Client Architecture

Mobile clients must be able to use net-works with rather unpleasant charac-teristics: intermittence, low bandwidth,high latency, or high expense. The con-nectivity with one or more of these prop-erties is referred to as weak connectiv-ity. In the extreme case, mobile clientswill be forced to work under the discon-nected mode. The ability to operate indisconnected mode can be useful evenwhen connectivity is available. For ex-ample, disconnected operations can ex-tend battery life by avoiding wirelesstransmission and reception. It can re-duce network charges, an importantfeature when charge rates are high. Itallows radio silence to be maintained, avital capability in military applications.

Finally, it is a viable fallback positionwhen network characteristics degradebeyond usability.

A full client architecture can be usedto effectively support the disconnectedor weakly connected clients. Comparedto a thin client architecture, the fullclient architecture is at the other ex-treme of the range of extended client-server model. The full client architec-ture supports the emulation of functionsof servers at the client host so thatapplications can be executed withoutfully connecting to remote servers. Theemulation can be supported through aproxy or a “lightweight” server residingon client hosts. For example, a proxycan emulate some database operationsto allow mobile users to work in a dis-connected mode. Systems, enabling thefull client architecture, include CODAand WebExpress.

Pad

InfoNet

Applications

Type ServerType Server

X11

Type Server

AudioFile

Application

Generic X

Application

X Telephone

Figure 9. InfoPad system layering.



3.3 Flexible Client-Server Architecture

Flexible client-server architecture gen-eralizes both thin client and full clientarchitectures in that the roles of clientsand servers and application logic can bedynamically relocated and performed onmobile and stationary hosts (see Figure10). In the flexible architecture, the dis-tinction between clients and serversmay be temporarily blurred for pur-poses of performance and availability.Furthermore, the connection betweenclients and servers can be dynamicallyestablished during the execution of ap-plications (e.g., for the service hand-offs).

3.3.1 Mobile Objects. Mobile objects(also known as mobile agents) are pro-gramming entities that can freely roamthe network. Mobile objects enable cli-ent functions to run not only on mobilehosts, but also on stationary hostsas well. Furthermore, mobile objectsallow clients to download the servercode to the mobile host for execution.Mobile objects can contain threads and,therefore, be active. They can maintainstate information and make intelligentdecisions using it. They differ fromdownloadable applets in that they canindependently roam among differentmachines and are not limited to beingdownloaded once from server to client.

AgentTcl (developed at Dartmouth Col-leage) [Gray 1995], Odyssey (developedby General Magic) [General Magic1997], and Aglets (developed by IBM)[IBM 1997] are examples of languagetools that can be used to develop mobileobjects.

One of the challenges to using mobileobjects in wireless environments is howto implement the object transportationin a frequently disconnected or a weaklyconnected environment. The Rover Tool-kit [Joseph et al. 1996; 1997] providesmobile application support based on themobile object idea. In the Rover Toolkit,a relocatable dynamic object (RDO) isan object (code and data) with a well-defined interface that can be dyna-mically loaded into a client computerfrom a server computer, or vice versa, toreduce client-server communication re-quirements.

3.3.2 Collaborative Groups. A com-monly occurring case may be severalusers disconnected from the rest of thesystem while actively collaborating; acanonical example is a group of col-leagues taking a business trip together.Rather than giving the members of thisdisconnected working group access onlyto the data that they had the foresightto copy to their personal machine, acollaborative group architecture grants

Client

User

Interface

Application Logic

Data

Server

Figure 10. A flexible client-server computing.



any group member access to any datathat is available to the group.

The architecture is based on a divi-sion of functionality between servers,which store data, and clients, whichread and write data managed by serv-ers. A server is any machine (e.g., amobile host) that holds a complete copyof one or more databases. A client isable to access data residing on anyserver to which it can communicate; andconversely, any machine holding a copyof a database, including personal lap-tops, should be willing to service readand write requests from other nearbymachines.

In this architecture, portable comput-ers can be servers for some databasesand clients for others. The Bayou sys-tem [Demers et al. 1994; Terry et al.1995] is an example that implementsthe collaborative group architecture.

3.3.3 Application-Specific Proxy. Theapplication-specific proxy acts as anintermediary between clients and serv-ers to perform computation-intensiveand storage-intensive tasks on behalf ofclients. An application-specific proxy ona stationary host supports proxy agents(which can be fixed or mobile) to dynam-ically “transcode” or “distill” applicationdata to reduce the bandwidth consump-tion between the proxy and the mobileclient. This proxy allows legacy andother nonstandard (including thin) cli-ents to inter-operate with existing serv-ers. From the client’s perspective, theproxy is simply a server that gets thedata from someplace else. The examplesof application-specific proxies are dis-cussed in Brooks et al. [1996], Brewer etal. [1998], and Zenel and Duchamp[1997].

3.3.4 Virtual Mobility of Servers. Ina wireless information system, informa-tion (data) servers are connected viafixed networks to provide informationservices to mobile users. The replication(or partition) of information servicescould help reduce the latency of remoteoperations and balance the workloads of

data servers in a distributed and multi-ple networks environment. The replica-tion of information services in differentnetworks can be used to support theapplication service handoffs for movingmobile clients.

In a wireless environment, the clientmoves around, perhaps to areas it hasnever visited before; once in a new mi-lieu (or a new network environment), itwill negotiate with some nearby ma-chine to become a new coordinator tocontinuously provide services for its op-erations. The movement of mobile hostsmay result in a long path of communica-tions in fixed networks because thephysical distance may not necessarilyreflect network and service distance be-tween the client and the server, espe-cially when the movement crosses theboundary of different networks. Thelong path of communication in fixed net-works will increase the traffic and la-tency of transactional services. If thenew coordinator could always use anearby or local information service siteas the client’s data server, the trafficand latency in fixed networks can bereduced for the continuous interactionbetween the client and the informationservice server. Therefore, the mobilityof the client introduces the concepts ofvirtual mobility of servers and applica-tion service handoffs.

An issue of supporting the virtual mo-bility of servers is to minimize the over-head of application service handoffs forsynchronous multi-server operations.The work in Tait and Duchamp [1991;1992] investigates how to maintain rep-licas in a distributed file system thatsupports mobile clients. This work as-sumes that (1) clients’ movements can-not be constrained, although patterns ofmovement may exist; (2) the latency ofremote operations increases as the dis-tance between hosts increases; (3) se-quential sharing workload is not un-common, but simultaneous sharing(other than read-read) workload is rare;and (4) a file cache of modest size ismaintained by each client. The designgoals in this work include: minimizing



synchronous multi-server operations;easing the addition and deletion ofserver sites; and allowing for incompletereplication.

To achieve these goals, a primary-secondary server hierarchy architectureis proposed, as shown in Figure 11. Typ-ically, the client need not contact any(remote) server, but it communicatessynchronously with the (local) primaryserver only. All updates are stored inthe client’s cache. The primary servermakes periodic pickups from the clientsit is currently servicing and propagatesupdates back to the secondary serversasynchronously. This pickup strategyallows the client’s write operation toreturn immediately after placing thenew value in its cache.

The primary servers are used as in-termediaries between clients and sec-ondary servers. Because the systemsupports replica addition/deletion andincomplete replication, a primary servermust learn about mapping from the filesystem to the secondary servers. Themapping is provided by calling a map-ping server function specified by the cli-ent. For example, someone from NewYork who is visiting Seattle would callthe Seattle matchmaker to obtain a lo-cal primary server site. The locally-cho-sen primary server then calls the map-ping server in New York to locate filesthat the client wishes to access. Afterthe handoff of primary servers, the newprimary server can lazily copy the cli-ent’s file from the old cache in the old

primary server. Therefore, this methodalways connects the mobile client to thelocal primary server for information ac-cess in a distributed file system.

The work in Krishnakumar and Jain[1994]; Jain and Krishnakumar [1994]presents a system architecture and ap-plication service handoff protocols forvirtual mobility of servers. The architec-ture is based on replicated distributedservers connected to users via a per-sonal communication services (PCS)network. Under this architecture, as theuser moves out of one service area intoanother, the local server at the newservice area takes over providing theservice. This service handoff for the vir-tual mobility of the server is broadlyanalogous to the PCS call handoff proce-dure and also requires that service con-tinuation is transparent with no inter-ruptions.

For the application services handoffs,a service coordinator, when informedthat the user has moved, initiates theset-up of a conference call between thecurrent server, the mobile host, and thenew server so that the service can betransparently handed off to the newserver. The coordinator can then termi-nate the call with the old server.

Before the new server takes over dur-ing a service handoff, it has to knowwhat the mobile user is currently doingwith the service, that is., the context ofthe user with respect to the service.Context information is the informationassociated with a user and a service so

Matchmaker

ServerMapping

Secondary 2

Secondary 1

PrimaryClient

Figure 11. The primary-secondary server hierarchy.



that the user can access different serv-ers transparently. Part of the context isstatic, including password and accessrights that do not change as the useraccesses information. However, the con-text also includes dynamic session-spe-cific data information such as how muchdata has been read or modified by theuser, whether the changes are meant tobe transactional, whether the user holdsany locks to access the data, and so on.In Elmagarmid et al. [1995], an ap-proach called Reservation Algorithm(RA) is proposed to avoid transaction logtransfer and the use of global commitprotocol.

4. MOBILE DATA ACCESS

Mobile data access enables the deliveryof server data and the maintenance ofclient-server data consistency in a mo-bile and wireless environment. Efficientand consistent data access in mobileenvironments is a challenge researcharea because of weak connectivity andresource constraints. The data accessstrategies in a mobile information sys-tem can be characterized by deliverymodes, data organizations, and consis-tency requirements, etc. The mode forserver data delivery can be server-push,client-pull, or hybrid. The server-pushdelivery is initiated by server functionsthat push data from the server to theclients. The client-pull delivery is initi-ated by client functions which send re-quests to a server and “pull” data from

the server in order to provide data tolocally running applications. The hybriddelivery uses both server-push and cli-ent-pull delivery. The data organiza-tions include mobility-specific data or-ganizations like mobile databasefragments in the server storage anddata multiplexing and indexing in thebroadcast disk. The consistency require-ments range from weak consistency tostrong consistency. Figure 12 illustratesthe new paradigm of mobile data accessfor mobile information access. In thissection, we will examine various pro-posed approaches that offer the newparadigm of data access in mobile cli-ent-server information systems.

4.1 Server Data Dissemination

In many applications (e.g., Web access),the downstream data volume from serv-ers to clients is much greater than theupstream data volume from clients backto servers. The unbalanced communica-tions are referred to as asymmetricalcommunications between clients andservers. Application examples of asym-metrical communications in wireless en-vironments include Hughes’s DirectPC(www.hns.com) and CAI’s Wireless In-ternet Access (www.caiwireless.net),where clients at mobile hosts usuallyhave a lower bandwidth cellular orPSTN link while servers at fixed hostsmay have relatively high bandwidthbroadcast capability.

A challenge problem in supporting ap-

Databases Cache

Push

Server Push

Client Pull

Client PullBroadcast

ChannelServer

ClientServer

Figure 12. A mobile data access paradigm.



plications with asymmetrical communi-cations is how to deliver server data andinformation to a large number of clients.To address this scalability problem, anew information system architecturethat exploits broadcast-based dissemi-nation capability of communications hasbeen proposed [Herman et al. 1987; Imi-elinski and Badrinath 1994; Acharya etal. 1995, 1997; Su and Tassiulas 1998].The central idea is that the servers ex-ploit the downstream communicationcapacity in bandwidth by broadcastingdata to multiple clients. This arrange-ment is called a push-based architec-ture where data is pushed from theserver to the clients. In contrast, mosttraditional client-server informationsystems use pull-based data delivery toprovide data to locally running applica-tions.

4.1.1 Broadcast Disks. When a servercontinuously and repeatedly broadcastsdata to a client community, the broadcastchannel becomes a “disk” from which cli-ents can retrieve data as it goes by. Thebroadcasting data can be organized asmultiple disks of different sizes andspeeds on the broadcast medium[Acharya et al. 1995]. The broadcast iscreated by multiplexing chunks of datafrom different disks onto the same broad-cast channel. The chunks of each disk areevenly interspersed with each other. Thechunks of the fast disks are repeatedmore often than the chunks of the slowdisks (see Figure 13). The relative speedsof these disks can be adjusted as a param-eter to the configuration of the broadcast.This use of the channel effectively puts

the fast disks closer to the client while atthe same time pushing the slower disksfurther away.

This technique presents an opportu-nity to more closely match the broadcastto the workload at the client. Assumingthat the server has an indication of theclient access patterns (either by watch-ing their previous activity or from adescription of intended future use fromeach client), then hot pages or pagesthat are more likely to be of interest to alarger part of the client community canbe brought closer while cold pages canbe pushed further away. This, in effect,creates an arbitrarily fine-grainedmemory hierarchy, as the expected de-lay in obtaining an item depends uponhow often that item is broadcast. Thebroadcast disk technique, therefore,provides improved performance for non-uniformly accessed data.

In the simplest scenario, the servercan broadcast different items at thesame frequency. With the “flat” broad-cast, the expected delay required priorto obtaining an item is the same for allitems broadcast (namely, half a broad-cast period) regardless of their relativeimportance to the clients. This “flat”approach has been adopted in earlierwork on broadcast-based informationsystem such as Datacycle [Herman etal. 1987] and the work in Imielinski etal. [1994a; 1994b]. By comparison, theserver can broadcast different itemswith differing frequency; importantitems can be broadcast more often thanothers.

A A

AA

FE

D

CBA

Figure 13. A broadcast program.



Similar to the broadcast disk concept,a pyramid broadcasting method is usedto provide Video-On-Demand services tomobile users [Vishwanath and Imielin-ski 1995]. In pyramid broadcasting, themost frequently requested movies aremultiplexed on the broadcast network,resulting in radical improvement of ac-cess time and efficient bandwidth utili-zation.

4.1.2 Indexing on Air. In the “push-based” approach, servers periodicallybroadcast most frequently requesteddata items (hot spots). The servershould dynamically adjust the contentof the broadcast hot spot, depending onthe periodically measured demand dis-tribution. The client is lazy in that ittransmits only when necessary. The cli-ent could also stay in the doze mode(turning the power off) as much as pos-sible. To minimize wake-up time, clientscan use selective tuning capabilities inthe broadcasting channel. In Imielinskiet al. [1994a; 1994b], the authors dis-cuss basic methods for data organiza-tion on the broadcast channel that pro-vide selective tuning capabilities forclients. In these methods, index infor-mation is broadcast together with thedata. The index is structured so that thefollowing two parameters are mini-mized:

—Query Time: Amount of time that ittakes for a client to issue a queryuntil the answer is received by theclient.

—Listening Time: Amount of time spentby the client listening to the channel.

Query time is proportional to the overallsize of the broadcast data. Therefore,the presence of the index increases thequery time since the presence of theindex increases the overall broadcastsize. However, the presence of the indexreduces the listening time. This, inturn, reduces energy consumption be-cause clients can use the selective lis-tening capabilities in broadcastingchannels to stay in the doze mode and

minimize wake-up time, as demon-strated in Imielinski et al. [1994a;1994b].

4.2 Client Cache Management

Caching of frequently-accessed dataitems is an important technique thatreduces contention and improves queryresponse times on narrow bandwidthwireless links. The cached data can alsosupport disconnected or intermittedconnected operations. However, cachepre-fetching and consistency strategiescan be greatly affected by the disconnec-tion or weak connectivity of mobile cli-ents. The weak connectivity makescache coherence expensive due to com-munication latency and intermittentfailures. Pre-fetching (or hoarding) datainto the client cache prior to disconnec-tion is a difficult challenge in mobileclient-server computing. This subsec-tion describes an automated hoardingapproach and two cache validationmechanisms.

4.2.1 Automated Hoarding. A usefulsolution to support disconnected opera-tions is hoarding, in which nonlocal filesare cached on the client cache prior todisconnection. The difficult issue forhoarding is which files should be se-lected and stored locally. Possible solu-tions include choosing the most recentlyreferenced files or asking the user toparticipate at least peripherally in man-aging hoard contents. The former ap-proach might be wasteful of scarcehoard space, while the latter requiresmore expertise and involvement thatmost users are willing to offer.

In the SEER system, an automatedpredictive hoarding approach is devel-oped [Kuenning and Popek 1997]. Theautomated predictive hoarding is basedon the idea that a system can observeuser behavior, make inferences aboutthe semantic relationships betweenfiles, and use those inferences to aid theuser. In SEER, an observer componentwatches the user’s behavior and file ac-cesses, classifying each access according



to type, converting path names to abso-lute format, and feeding the results to acorrelator component. The correlatorcomponent evaluates the file references,calculating the semantic distancesamong various files. These semanticdistances drive a clustering algorithmthat assigns each file to one or moreprojects. When new hoard contents areto be chosen, the correlator componentexamines the projects to find those thatare currently active, and selects thehighest-priority projects until the maxi-mum hoard size is reached. In this way,SEER is able to operate without userintervention (though the user might in-volve informing the computer that adisconnection is imminent).

The fundamental assumption ofSEER is that there is semantic localityin user behavior. By detecting and ex-ploiting this locality, a system can makeinferences about the relationships be-tween various files. Once these relation-ships are known, it is possible to auto-mate the hoarding. To detect semanticlocality, SEER uses a concept known assemantic distance. Conceptually, se-mantic distance attempts to quantify auser’s intuition about the relationshipbetween files. A low semantic distancesuggests that the files are closely re-lated and thus are probably involved inthe same project, while a large valueindicates relative independence and dif-ferent projects.

The semantic distance is based onmeasurements of individual file refer-ences, rather than looking at the filesthemselves. The distance between refer-ences is then summarized to produce avalue that is relevant to the individualfiles. Several semantic distance mea-surement methods are defined based onfile references in Kuenning and Popek[1997].

4.2.2 Varied Granularity of Cache Co-herence. Consistency methods in tradi-tional client-server architecture can bedivided into two categories: (1) callbackapproach when servers send invalida-tion messages directly to the clients

that have cached the data items to beupdated and (2) detection approachwhen clients send queries to servers tovalidate cached data. The difficulty ofusing these traditional methods in mo-bile environments is due to the discon-nection and weak connectivity of clients.Frequently disconnected clients make itvery ineffective to use the detection ap-proach. On the other hand, the classiccallback approach may also be very ex-pensive, due to network latency or in-termittent failures. After a long discon-nection, many data items at the serverside may have been updated. In thiscase, the time for the callback invalida-tion of each data item can be substan-tial on a low network.

In the Coda system [Satyanarayananet al. 1990; Kistler and Satyanarayanan1992; Mummert and Satyanarayanan1994], clients can track the server stateat multiple levels of granularity. Aserver maintains version stamps foreach of its file volumes, in addition tostamps on individual objects (or items).When an object is updated, the serverincrements the version stamp of the ob-ject and that of its containing volume.Clients cache volume version stamps inanticipation of disconnection.

When connectivity is restored after anetwork failure, the client presents vol-ume stamps for validation. If a volumestamp is still valid, then so is everyobject cached from the volume. If a vol-ume stamp is not valid, cached objectsfrom the volume need to be validatedindividually. Even in this case, perfor-mance is no worse than in the originalscheme [Mummert and Satyanarayanan1994]. On the other hand, if the valida-tion for each individual data item is notpossible due to slow connections, theclient can assume that all items in thevolume are invalid or defer the valida-tion until the time when the item isused. The experiments and measure-ments from the Coda system confirmthat the varied granularity of cache co-herence dramatically improve the speedof cache validation [Mummert and Saty-anarayanan 1994].



4.2.3 Cache Invalidation Reports. Adissemination-based approach to theproblem of invalidating caches in wire-less environments is proposed in Bar-bara and Imielinski [1994] by utilizingwireless broadcast channels. In this ap-proach, a server periodically broadcastsan invalidation report that reports dataitems which have been changed. Ratherthan querying a server directly regard-ing the validation of cached copies, cli-ents listen to these invalidation reportsover broadcast channels. This approachis attractive because a server does notneed to know the location and connec-tion status of its clients, and the clientsdo not need to establish an “uplink”connection to the server to invalidatetheir caches.

Three algorithms are presented inBarbara and Imielinski [1994], namely,the Broadcasting Timestamps (TS), Am-nesic Terminals (AT), and Signatures(SIG). In the TS algorithm, the invalida-tion report includes only the informa-tion regarding the data items that havebeen updated within the preceding wseconds. The report includes the namesof these items and the timestamps atwhich they were updated. The invalida-tion report in the AT algorithm includesthe identifiers of data items that wereupdated during the last broadcast pe-riod L. In both the TS and AT algo-rithms, clients must invalidate their en-tire cache when their disconnectionperiod exceeds a specified length (w sec-onds for TS and L seconds for AT). Inthe SIG algorithm, the report contains aset of combined signatures of dataitems.2 The structure and size of thesesignatures are designed to diagnose up

to f differing items. If more than f dif-ferent items (it does not matter whetherthese items had been cached or not) areupdated in the data server since thecombined signatures were last cached,most items cached by the clients will beinvalidated by the SIG algorithm, al-though many are in fact valid.

An improved invalidation reportmethod called Bits-Sequences (BS) isproposed in Jing et al. [1997]; thismethod adapts to long disconnected cli-ents. In the Bit-Sequences (BS) algo-rithm, the server broadcasts a set of bitsequences. Each sequence consists of aseries of binary bits and is associatedwith a timestamp. Each bit represents adata item in a database. A bit “1” in asequence means that the item repre-sented by the bit has been updatedsince the time specified by the times-tamp of the sequence. A bit “0” meansthat that item has not been updatedsince that time.

Clients must check the invalidationreport before they can use their cachesfor query processing. If a bit sequenceamong the sequence set with the mostrecent timestamp equals to or predatesthe disconnection time of the client, thesequence will be used to invalidate itscaches. The data items represented bythese “1” bits in the sequence will beinvalidated. If there is no such sequence(i.e., the disconnection time precedesthe timestamp of the highest sequence),the entire cache in the client will beinvalidated.

Consider a database consisting of 16data items. Figure 14 shows a Bit-Se-quences (BS) structure reported by aserver at the time 250. Suppose a clientlistens to the report after having sleptfor 80 time units. That is, the clientdisconnected at the time 170 (5250-80),which is larger than TS~B2! but lessthan TS~B1!. The client will then useB2 to invalidate its caches. To locate theitems denoted by the two “1” bits in B2,the client will check both B3 and B4sequences, using the following proce-

2Signatures are checksums computed over thevalue of data items in the database. A combinedsignature is the Exclusive OR of a set of individ-ual signatures. Each combined signature, there-fore, represents a subset of data items. In the SIGalgorithm, m combined signatures are computedsuch that an item i is in the set of combinedsignature Sj (1 # j # m) with probability 1/~f1 1!, where f is the number of differing items upto which the algorithm can diagnose.



dure. To locate the second bit that is setto “1” in B2, check the position of thesecond “1” bit in B3. The second “1” bitin B3 is in the 5th position; therefore,check the position of the 5th “1” bit inB4. Because B4 is the highest sequenceand the 5th “1” bit in B4 is in the 8thposition, the client concludes that the8th data item was updated since thetime 170. Similarly, the client can de-duce that the 12th data item has alsobeen updated since that time. There-fore, both the 8th and 12th data itemswill be invalidated. This method workseffectively for clients who have beendisconnected for a long time. It opti-mizes the utilization of bandwidth forinvalidation report.

In Pitoura and Samaras [1998], a re-vised version of invalidation reports isdesigned to provide the semantics ofread-only transactions for mobile clientswithout sending uplink requests toservers.

5. CASE STUDIES

We conclude this review with a study ofthree prototype systems for mobile in-formation access. These systems serveas a means of demonstrating how newparadigms analyzed in the previous sec-

tions are being applied in practice. Thethree systems, namely, Bayou, Odyssey,and Rover, demonstrate some ap-proaches of new paradigms for mobileclient-server computing. Bayou providesa flexible client-server architecture inwhich a server can be any machine thatholds a complete copy of one or moredatabases. A portable computer mayalso act as a server for some databasesand as a client for others. Odyssey sup-ports application-aware adaptationbased on type-specific operations. Roverprovides a toolkit for distributed object-based client-server computing. The relo-catable objects in Rover enable a flexi-ble client-server architecture for mobileapplications. The toolkit supports bothapplication-transparent and applica-tion-aware adaptation.

5.1 Bayou

Bayou is a Xerox PARC research projectled by Douglas Terry. It is designed forcollaborative applications in a mobilecomputing environment containing por-table machines with intermittent net-work connectivity [Demers et al. 1994;Terry et al. 1994, 1995]. The focus of theBayou system has been on exploringmechanisms that let mobile clients ac-

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

1 0 0 0 1 1 1 1 0 1 0 1 0 0 0 1

0 0 0 1 1 0 1 1

1 0

0 1 1 0

B1

B4

TS(B1)=200

TS(B2)=160

TS(B3)=140

TS(B4)=50

B3

B2

Figure 14. A Bit-Sequences example.



tively read and write shared data, suchas appointment calendars, bibliographicdatabases, meeting notes, evolving de-sign documents, news bulletin boardsetc.

Bayou supports application-specificmechanisms that detect and resolve theupdate conflicts, ensures that replicasmove towards eventual consistency, anddefines a protocol by which the resolu-tion of update conflicts stabilizes. Bayouincludes consistency management meth-ods for conflict detection, called depen-dency checks, and per-write conflict res-olution based on client-provided mergeprocedures. To guarantee eventual con-sistency, Bayou servers are able to roll-back the effects of previously executedwrites and redo them according to aglobal serialization order. Furthermore,Bayou permits clients to observe theresults of all writes received by a server,including tentative writes whose con-flicts have not been ultimately resolved.

5.1.1 The System Model. In theBayou system, each data collection isreplicated in full at a number of servers.

Applications running as clients interactwith the servers through the Bayou ap-plication programming interface (API),which is implemented as a client stubbound with the application. This API, aswell as the underlying client-serverRPC protocol, supports two basic opera-tions: Read and Write. Read operationspermit queries over a data collection,while Write operations can insert, mod-ify, and delete a number of data itemsin a collection. Figure 15 illustratesthese components of the Bayou architec-ture. In the Bayou system, a client anda server may be co-resident on a host, aswould be typical of a laptop or PDArunning in isolation.

Access to one server is sufficient for aclient to perform useful work. The clientcan read the data held by that server andsubmit Writes to the server. Once a Writeis accepted by a server, the client has nofurther responsibility for that Write. Inparticular, the client does not need towait for the Write to propagate to otherservers. In other words, Bayou presents aweakly consistent replication model with

CLIENT

SERVER

SERVER

SERVER

Anti-entropy

SERVER

CLIENT

SystemStorage

Server State

Server State

StorageSystem

Server State

StorageSystem

SystemStorage

Server State

Application

Bayou API

Client Stub

Client Stub

Bayou API

Application

Reador

Write

Writeor

Read

Figure 15. The Bayou system model..



a read-any/write-any style of access.While individual Read and Write opera-tions are performed at a single server,clients need not confine themselves tointeracting with a single server. In a mo-bile computing environment, switchingbetween servers is often desirable, andBayou provides session guarantees to re-duce client-observed inconsistencies whenaccessing different servers.

5.1.2 Bayou Application-Specific Con-flict Resolution. Application-specificconflict detection is adopted in theBayou system. This approach is moti-vated by the observation that differentapplications have different notions ofwhat it means for two updates to con-flict, and that such conflicts cannot al-ways be identified by simply observingconventional reads and writes submit-ted by the applications. In Bayou, stor-age systems provide means for an appli-cation to specify its notion of a conflictalong with its policy for resolving con-flicts. In return, the system implementsmechanisms for reliably detecting con-flicts, as specified by the application,and for automatically resolving themwhen possible.

The Bayou system includes two mech-anisms for automatic conflict detectionand resolution that are intended to sup-port arbitrary applications: dependencychecks and merge procedures. Thesemechanisms permit clients to indicate,for each individual write operation, howthe system should detect conflicts in-volving the write and what steps shouldbe taken to resolve any detected con-flicts based on the semantics of the ap-plication.

Application-specific conflict detectionis accomplished as follows: Each Writeoperation includes a dependency checkconsisting of an application-suppliedquery and its expected result. A conflictis detected if the query, when run at aserver against its current copy of thedata, does not return the expected re-sult. This dependency check is a precon-dition for performing the update that isincluded in the Write operation. If the

check fails, then the requested update isnot performed and the server invokes aprocedure to resolve the detected con-flict.

As an example of application-definedconflicts, consider a Bayou Write opera-tion that might be submitted by themeeting room scheduling application.This Write attempts to reserve an hour-long time slot. It includes a dependencycheck with a single query that returnsinformation about any previously re-served meetings that overlap with thistime slot. It expects the query to returnan empty set.

Bayou’s dependency checks can alsobe used to detect Write-Write conflicts.That is, they can be used to detect whentwo users update the same data itemwithout one of them first observing theother’s update. Such conflicts can bedetected by having the dependencycheck query the current values of anydata items being updated and ensurethat they have not changed from thevalues they had at the time the Writewas submitted.

Bayou’s dependency checking mecha-nism is more powerful than the tradi-tional use of version vectors since it canalso be used to detect Read-Write con-flicts. Specifically, each Write operationcan explicitly specify the expected val-ues of any data items on which theupdate depends, including data itemsthat have been read but are not beingupdated. Thus, Bayou clients can emu-late the optimistic style of concurrencycontrol employed in some distributeddatabase systems. For example, a Writeoperation that installs a new programbinary file might only include a depen-dency check of the sources, includingversion stamps, from which it was de-rived. Since the binary does not dependon its previous value, this need not beincluded.

Moreover, because dependency que-ries can read any data in the server’sreplica, dependency checks can enforcearbitrary, multi-item integrity con-straints on the data. For example, sup-pose a Write transfers $100 from ac-



count A to account B. The application,before issuing the Write, reads the bal-ance of account A and discovers that itcurrently has $150. Traditional optimis-tic concurrency control would check thataccount A still had $150 before perform-ing the requested Write operation. Thereal requirement, however, is that theaccount have at least $100, and this caneasily be specified in the Write’s depen-dency check. Thus, only if concurrentupdates cause the balance in account Ato drop below $100 will a conflict bedetected.

Once a conflict is detected, a mergeprocedure is run by the Bayou server inan attempt to resolve the conflict.Merge procedures, included with eachWrite operation, are general programswritten in a high-level, interpreted lan-guage. They can have embedded data,such as application-specific knowledgerelated to the update that was beingattempted, and can perform arbitraryReads on the current state of the serv-er’s replica. The merge procedure asso-ciated with a Write is responsible forresolving any conflicts detected by itsdependency check and for producing arevised update to apply. The completeprocess of detecting a conflict, running amerge procedure, and applying the re-vised update is performed atomically ateach server as part of executing a Write.Supporting dependency checks sepa-rately allows servers to avoid runningthe merge procedure in the expectedcase where the Write does not introducea conflict.

Bayou merge procedures are writtenby application programmers in the formof templates that are instantiated withthe appropriate details filled in for eachWrite. The users of applications do nothave to know about merge proceduresand, therefore, about the internal work-ings of the applications they use, exceptwhen automatic conflict resolution can-not be done. In the case where auto-matic resolution is not possible, themerge procedure will still run to com-pletion, but it is expected to produce arevised update that logs the detected

conflict in a way that will enable aperson to resolve the conflict later. Toenable manual resolution, the conflict-ing updates must be presented to a userin a manner that allows him to under-stand what has happened.

Bayou allows replicas to always re-main accessible. This permits clients tocontinue to Read previously writtendata and to continue to issue newWrites. In the meeting room schedulingapplication, for example, a user whoonly cares about Monday meetings neednot concern himself with schedulingconflicts on Wednesday. The potentialdrawback of this approach is that newlyissued Writes may depend on data thatis in conflict and may lead to cascadedconflict resolution.

5.1.3 Bayou Replication Management.While the replicas held by two serversat any time may vary in their contentsbecause they have received and pro-cessed different Writes, a fundamentalproperty of the Bayou design is that allservers move towards eventual consis-tency. However, it cannot enforce strictbounds on Write propagation delayssince these depend on network connec-tivity factors that are outside of Bayou’scontrol. Two important features of theBayou system design allow servers toachieve eventual consistency. First,Writes are performed in the same, well-defined order at all servers. Second, theconflict detection and merge proceduresare deterministic so that servers resolvethe same conflicts in the same manner.

When a Write is accepted by a Bayouserver from a client, it is initiallydeemed tentative. Tentative Writes areordered according to timestamps as-signed to them by their accepting serv-ers. Committed Writes are ordered ac-cording to the times at which theycommit and before any tentative Writes.

The only requirement placed on time-stamps for tentative Writes is that theyshould be monotonically increasing ateach server so that the pair [timestamp,ID of server that assigned it] produce atotal order on Write operations. Bayou



servers maintain logical clocks to times-tamp new Writes. A server’s logicalclock is generally synchronized with itsreal-time system clock, but, in order topreserve the causal ordering of Writeoperations, the server may need to ad-vance its logical clock when Writes arereceived during anti-entropy.

Enforcing a global order on tentativeas well as committed Writes ensuresthat an isolated cluster of servers willcome to agreement on the tentative res-olution of any conflicts that they en-counter. This is not strictly necessarysince clients must be prepared to dealwith temporarily inconsistent servers inany case. Moreover, clients can expectthat the tentative resolution of conflictswithin their cluster will correspond totheir eventual permanent resolution,provided that no further conflicts areintroduced outside the cluster.

Because servers may receive Writesfrom clients and from other servers inan order that differs from the requiredexecution order, and because serversimmediately apply all known Writes totheir replicas, servers must be able toundo the effects of a previous tentativeexecution of a Write operation and reap-ply it in a different order. The numberof times that a given Write operation isre-executed depends only on the orderin which Writes arrive via anti-entropyand not on the likelihood of conflictsinvolving the Write. Conceptually, eachserver maintains a log of all Write oper-ations that it has received, sorted bytheir committed or tentative times-tamps, with committed Writes at thehead of the log. The server’s currentdata contents are generated by execut-ing all of the Writes in the given order.

Bayou guarantees that merge proce-dures, which execute independently ateach server, produce consistent updatesby forcing them to depend only on theserver’s current data contents and onany data supplied by the merge proce-dure itself. In particular, a merge proce-dure cannot access time-varying or serv-er-specific “environment” informationsuch as the current system clock or

server’s name. Moreover, merge proce-dures that fail due to exceeding theirlimits on resource usage must fail deter-ministically. This means that all serv-ers must place uniform bounds on theCPU and memory resources allocated toa merge procedure and must consis-tently enforce these bounds during exe-cution. Once these conditions are met,two servers that start with identicalreplicas will end up with identical repli-cas after executing a Write.

5.1.4 Bayou Applications. The Bayousystem is designed to support a varietyof non-real-time collaborative applica-tions, such as shared calendars, mailand bibliographic databases, programdevelopment, and document editing fordisconnected workgroups, as well as ap-plications that might be used by indi-viduals at different hosts at differenttimes.

Meeting Room Scheduler: The meet-ing room scheduling application enablesusers to reserve meeting rooms. Atmost, one person or group can reservethe room for any given period of time.This meeting room scheduling programis intended for use after a group ofpeople have already decided that theywant to meet in a certain room and havedetermined a set of acceptable times forthe meeting. It does not help them todetermine a mutually agreeable placeand time for the meeting; it only allowsthem to reserve the room. Thus, it is amuch simpler application than one thatsupports general meeting scheduling.

In this application, Bayou users couldinteract with a graphical interface forthe schedule of a room that indicateswhich times are already reserved, muchlike the display of a typical calendarmanager. The meeting room schedulingprogram periodically re-reads the roomschedule and refreshes the user’s dis-play. This refresh process enables theuser to observe new entries added byother users. The user’s display might beout-of-date with respect to the con-firmed reservations of the room; for ex-



ample, when it is showing a local copy ofthe room schedule on a disconnectedlaptop.

Bayou users reserve a time slot sim-ply by selecting a free time period andfilling in a form describing the meeting.Because the user’s display might be out-of-date, there is a chance that the usercould try to schedule a meeting at atime that was already reserved bysomeone else. To account for this possi-bility, users can select several accept-able meeting times rather than just one.At most, one of the requested times willeventually be reserved.

A user’s reservation, rather than be-ing immediately confirmed (or rejected),may remain “tentative” for a while.While tentative, a meeting may be re-scheduled as other interfering reserva-tions become known. Tentative reserva-tions are indicated as such on thedisplay (by showing them grayed). The“outdatedness” of a calendar does notprevent it from being useful, but simplyincreases the likelihood that tentativeroom reservations will be rescheduledand finally “committed” to less pre-ferred meeting times.

A group of Bayou users, although dis-connected from the rest of the system,can immediately see each other’s tenta-tive room reservations if they are allconnected to the same copy of the meet-ing room schedule. If, instead, users aremaintaining private copies on their lap-top computers, local communication be-tween the machines will eventually syn-chronize all copies within the group.

The meeting room scheduling applica-tion provides good examples of conflictresolution procedures that are specificnot only to a particular application butalso to a particular Write operation. Inthis application, users, well aware thattheir reservations may be invalidatedby other concurrent users, can specifyalternate scheduling choices as part oftheir original scheduling updates. Thesealternates are encoded in a merge pro-cedure that attempts to reserve one ofthe alternate meeting times if the origi-nal time is found to be in conflict with

some other previously scheduled meet-ing. A different merge procedure alto-gether could search for the next avail-able time slot to schedule the meeting,which is an option a user might chooseif any time would be satisfactory.

Bibliographic Database: The applica-tion allows users to cooperatively man-age databases of bibliographic entries.A user can freely read and write to anycopy of the database, such as the onethat resides on his laptop. For the mostpart, the database is append-only,though users occasionally update en-tries to fix mistakes or add personalannotations.

In bibliographic databases, each entryhas a unique, human-sensible key thatis constructed by appending the year inwhich the paper was published to thefirst author’s last name and adding acharacter if necessary to distinguish be-tween multiple papers by the same au-thor in the same year. Thus, the firstpaper by Jones et al. in 1995 might beidentified as “Jones95” and subsequentpapers as “Jones95b”, “Jones95c”, andso on.

An entry’s key is tentatively assignedwhen the entry is added. A user must beaware that the assigned keys are onlytentative and may change when the en-try is “committed” In other words, auser must be aware that other concur-rent updaters could be trying to assignthe same key to different entries. Onlyone entry can have the key; the otherswill be assigned alternative keys by thesystem. Thus, for example, if the useremploys the tentatively assigned key insome fashion, such as embedding it as acitation in a document, then he mustalso remember to check later that thekey assigned when the entry was com-mitted is, in fact, the expected one.

Because users can access inconsistentdatabase copies, the same bibliographicentry may be concurrently added by dif-ferent users with different keys. To theextent possible, the system detects du-plicates and merges their contents intoa single entry with a single key. In this



application, a Bayou user may choose tooperate in disconnected mode even ifconstant connectivity were possible. Forexample, a Bayou user may be in auniversity library looking up papers. Heoccasionally types bibliographic refer-ences into his laptop or PDA.

5.2 Odyssey

Odyssey is a CMU research project ledby M. Satyanarayanan. It addresses anapplication-aware adaptation approachto deal with application diversity andconcurrency in mobile environments.The application-aware adaptation is im-plemented with the support of system-coordinated type-specific operations. Itsupports concurrent execution of di-verse mobile applications that executeon mobile clients, but read or updateremote data on servers [Kumar andSatyanarayanan 1993; Satyanarayananet al. 1995; Noble et al. 1995, 1997].

5.2.1 Odyssey Client Architecture.In Odyssey, the data accessed by anapplication may be stored in one ormore general-purpose repositories suchas file servers, SQL servers, or Webservers. It may also be stored in morespecialized repositories such as videolibraries, query-by-image-content data-bases, or back-ends of geographical in-formation systems.

Ideally, a data item available on amobile client should be indistinguish-able from that available to the accessingapplication if it were to be executed onthe server storing that item. But thiscorrespondence may be difficult to pre-serve as mobile resources becomescarce; some form of degradation maybe inevitable. In Odyssey, fidelity isused to describe the degree to whichdata presented at a client matches thereference copy at the server. Fidelityhas many dimensions. One well-known,universal dimension is consistency. ForVideo applications, data has at leasttwo additional dimensions: frame rateand image quality of individual frames.Odyssey provides a framework within

which diverse notions of fidelity can beincorporated.

Odyssey implements an approach ofapplication-aware adaptation. The sys-tem monitors resource levels, notifiesapplications of relevant changes, andenforces resource allocation decisions.Each application independently decideshow best to adapt when notified. Odys-sey incorporates type-awareness viaspecialized code components called war-dens. A warden encapsulates the sys-tem-level support at a client necessaryto effectively manage a data type. Tofully support a new data type, an appro-priate warden has to be written andincorporated into Odyssey at each cli-ent. The wardens are subordinate to atype-independent component called theviceroy, which is responsible for central-ized resource management (see Figure16). The collaborative relationship inthe application-aware adaptation is re-alized in two parts. The first, betweenthe viceroy and its wardens, is data-centric: it defines the fidelity levels foreach data type and factors them intoresource management. The second, be-tween applications and Odyssey, is ac-tion-centric: it provides applicationswith control over the selection of fidelitylevels supported by the wardens.

5.2.2 Odyssey System Components.Odyssey supports application-aware ad-aptation by enabling an application to

—operate on Odyssey objects,

Applications

API Extensions (Kernel)

Cache Manager

SupportType-Specific

Wardens

Generic Support

Viceroy

Figure 16. Odyssey client architecture.



—express resource expectations,

—be notified when expectations are nolonger met, and

—respond by changing fidelity.

Operating on Odyssey Objects: Odys-sey is integrated into NetBSD as a newVFS file system [Noble et al. 1997]. Asshown in Figure 16, the viceroy andwardens are implemented in user spacerather than in the kernel. Operations onOdyssey objects are redirected to theviceroy by a small in-kernel interceptormodule. All other system calls are han-dled directly by NetBSD.

Wardens are statically linked withthe viceroy, and the ensemble executesin a single address space with user-levelthreads. Communication between theviceroy and wardens is through proce-dure calls and shared data structures.The wardens are entirely responsiblefor communicating with servers andcaching data from them when appropri-ate; applications never contact serversdirectly.

Expressing Resource Expectations:Applications communicate resource ex-pectations to Odyssey using the requestsystem call shown in Figure 17(a). Thecall takes a resource descriptor identify-ing a resource and specifying a windowof tolerance based upon availability.This call expresses the application’s de-sire to be told if the availability of theresource strays outside the window. If,at the time of the request, the availabil-ity of the resource is within the windowof tolerance, the viceroy registers therequest and returns a unique identifierfor it. This identifier can be used by theviceroy in notifying the application thatthe resource has left the requestedbounds or by the application in a futurecancel system call to discard the regis-tered request.

If the resource is currently outsidethe bounds of the tolerance window, anerror code and the current available re-source level are returned. The applica-tion is then expected to try again, but

this time with a new window of toler-ance that corresponds to a new fidelitylevel. The fields of a resource descriptorare shown in Figure 17(b). Each re-source is named by a unique resourceidentifier. Figure 17(c) lists the genericresources that Odyssey manages. Themost critical resource in mobile comput-ing is the network bandwidth. The win-dow of tolerance is indicated by lowerand upper bounds. A resource descriptoralso specifies the name of a procedurethat will be called to notify the applica-tion that the resource has left the win-dow.

Notifying Applications: When theviceroy discovers that the availability ofa resource has strayed outside a regis-tered window of tolerance, it generatesan upcall to the corresponding applica-tion. The application adjusts its fidelityaccording to its individual policy. Itthen issues another request call to reg-ister a revised window of tolerance ap-propriate to the new fidelity.

(e) Type-Specific Operations

inout outsize, out outbuf)tsop(in path, in opcode, in insize, in inbuf,

(d) Upcall Handler

handler(in request-id, in resource-id, id resource-level)

(c) Generic Resource in Odyssey

centsMoneyminutesBattery PowerSPECCint95CPUkilobytesDisk Cache SpacemicrosecondsNetwork Latencybytes/secondNetwork Bandwidth

(a) Resource Negotiation Operations

cancel(in request-id)

request(in path, in resource-descriptor, out request-id)

resource-idlower boundupper boundname of upcall handler

(b) Resource Descriptor Fields

Figure 17. Odyssey API.



An upcall handler is invoked withthree parameters, as shown in Figure17(d). The first parameter identifies therequest operation on whose behalf theupcall is being delivered. The secondparameter identifies the resource whoseavailability has changed, and the thirdparameter gives the new availability.Upcalls closely resemble UNIX signals,but offer improved functionality. Likesignals, upcalls can be sent to one ormore processes, can be blocked or ig-nored, and have similar inheritance se-mantics on the process fork. Unlike sig-nals, upcalls offer semantics in aspecific order only once for each receiverof a particular upcall. Further, upcallsallow parameters to be passed to targetprocesses and results to be returned.

Changing Fidelity: Requests for fidel-ity changes do not map well to the Net-BSD file system interface. Further,many data types have natural accessmethods that are not well supported bythe untyped byte stream model. To ad-dress these shortcomings, a general es-cape purpose mechanism called tsop, ortype-specific operation, is includedshown in Figure 17(e). The argumentsto tsop specify an Odyssey object andthe opcode of a type-specific operation tobe performed on it. Input and outputparameters are specified as unstruc-tured memory buffers, in the spirit ofthe ioctl system call.

5.2.3 Odyssey Applications. Severalapplications are modified to demon-strate Odyssey’s ability to support ap-plication diversity. Two of them aredrawn from the domain of mobile infor-

mation access: a video player and a Webbrowser. Each application requires adifferent strategy for integration intoOdyssey, and each has distinct notionsof fidelity.

Video Player: Video Player is based onxanim, a public-domain software pack-age that can generate video animationfrom data stored in various formats in alocal file. A warden is written to satisfyclient requests and fetch data from theserver, as shown in Figure 18.

Each movie is stored in multipletracks at the server, one track per fidel-ity level. Three levels of fidelity forQuicktime video data are incorporated:JPEG-compressed color frames at quali-ties 99 and 50, and black-and-whiteframes. The warden supports two tsops:to read a movie’s meta-data and to get aparticular frame from a specified track.The warden performs read-ahead offrames to lower latency. When theplayer opens a movie, it calculates thebandwidth requirements of each trackfrom the movie meta-data. The playerbegins the movie at highest possiblequality and registers the correspondingwindow of tolerance with Odyssey.When it is notified of a significantchange in bandwidth, the player deter-mines a new fidelity level and switchesto the corresponding track. If the playerswitches from a low fidelity track to ahigher one, the warden discards theprefetched low-quality frames.

Web Browser: Netscape browser’sproxy facility is exploited to take advan-tage of Odyssey, as shown in Figure 19.All of Netscape’s requests are redirected

CLIENT

API

Odyssey RPC

Server

Video

Warden

Video

Viceroy

Xanim

Figure 18. Video player in Odyssey.



to a client module called the cellophane.Together, Netscape and the cellophaneconstitute a single application from theviewpoint of Odyssey. The cellophanemakes use of the Odyssey API and se-lects fidelity levels. Netscape passivelybenefits from the adaptation initiatedby the cellophane. The cellophane trans-forms HTTP requests from Netscapeinto file operations on Odyssey Web ob-jects. The Web warden forwards theserequests via the client’s mobile networkconnection to a distillation server. Atthe highest fidelity, images are uncom-pressed. Progressively lower levels cor-respond to JPEG-compressed images ofdecreasing quality. The warden pro-vides a tsop to set the fidelity level. Thedistillation server fetches requested ob-jects from the appropriate Web server,distills them to the requested fidelitylevel, and sends the results to the war-den. The data is then passed toNetscape via the cellophane. Thesesteps are completely transparent toboth Netscape and the Web server; eachperceives normal Web access.

5.3 Rover

Rover is a research project at MIT ledby M. Kaashoek. The Rover toolkit of-fers an environment to support bothapplication-transparent and applica-tion-aware adaptation for mobile client-server applications [Joseph et al. 1996;1997]. The application-transparent ad-aptation is realized by developing prox-ies for system services that hide themobile characteristics of the environ-ment from applications. The applica-tion-aware adaptation is supported by

the use of relocatable dynamic objects inthe construction of client and serverapplications. The Rover toolkit providesa framework to construct mobile appli-cations with flexible client-server archi-tecture.

5.3.1 Rover Toolkits. The RoverToolkit offers applications a distributedobject system based on a client-serverarchitecture [Joseph et al. 1997] (seeFigure 20). Clients are Rover applica-tions that typically run on mobile hosts,but can also run on stationary hosts aswell. Servers, which may be replicated,typically run on stationary hosts andhold the long-term state of the system.Communication between clients is lim-ited to peer-to-peer interactions withina mobile host (using the local objectcache for sharing) and mobile host-server interactions; there is no supportfor peer-to-peer, mobile host to mobilehost interactions. The Rover toolkit pro-vides mobile communication supportbased on two ideas: relocatable dynamicobject (RDO) and queued remote proce-dure call (QRPC). A relocatable dynamicobject is an object (code and data) with awell-defined interface that can be dy-namically loaded into a client computerfrom a server computer, or vice versa, toreduce client-server communication re-quirements. Queued remote procedurecall is a communication system thatpermits applications to continue tomake nonblocking remote procedurecalls even when a host is disconnected—requests and responses are exchangedupon network reconnection.

Rover gives applications control overthe location where the computation will

BrowserWeb

to Web Servers

ServerDistillation

HTTPHTTP API

Odyssey

CLIENT

RPC

Warden

Video

Viceroy

Cellophane

Figure 19. Web browser in Odyssey.



be performed. In an intermittently con-nected environment, the network oftenseparates an application from the dataupon which it is dependent. By movingRDOs across the network, applicationscan move data and/or computation fromthe client to the server and vice versa.

Use of RDOs allows mobile-aware ap-plications to migrate functionality dy-namically to either side of a slow net-work connection to minimize theamount of data communicated acrossthe network. Caching RDOs reduces la-tency and bandwidth consumption. In-terface functionality can run at fullspeed on a mobile host while large datamanipulations may be performed on thewell-connected server. All applicationcode and all application-touched dataare written as RDOs. RDOs may exe-cute at either the client or the server.Each RDO has a “home” server thatmaintains the primary, canonical copy.Clients import secondary copies ofRDOs into their local caches and exporttentatively updated RDOs back to theirhome servers. RDOs may vary in com-plexity from simple calendar items witha small set of operations to modulesthat encapsulate a significant part of anapplication (e.g., the graphical user in-terface for an email browser). ComplexRDOs may create a thread of controlwhen they are imported.

Rover clients use QRPC to lazily fetchRDOs from servers (see Figure 20).When an application issues a QRPC,Rover stores the QRPC in a local stablelog and immediately returns control tothe application. If the application hasregistered a callback routine, then whenthe requested RDO has arrived, Roverwill invoke the callback to notify theapplication. Alternatively, applicationsmay simply block to wait for criticaldata (although this is an undesirableaction, especially when the mobile hostis disconnected). When the mobile hostis connected, the Rover network sched-uler drains the log in the background,forwarding any queued QRPCs to theserver.

When a Rover application modifies alocally cached RDO, the cached copy ismarked tentatively committed. Updatesare committed by using QRPC to lazilypropagate the mutating operations tothe Rover server, where they are ap-plied to the canonical copies. In themeantime, the application may chooseto use tentatively committed RDOs.This allows the application to continueexecution even if the mobile host is dis-connected.

As shown in Figure 21, the RoverToolkit consists of four key components:the access manager, the object cache(client-side only), the operation log, and

Network

Schedule

Network

Schedule

Rover Library

Rover Library

Server

Modify/Resolve

Object Conflict?

Server-side Application

RDOExport RDO

RDO

Import RDO

ClientApplicationApplication

on Mobile Host

Client

QPRC Log

Object Cache

Access Manager Server

Modify/Resolve

Object Conflict?

Server-side Application

RDOExport RDO

RDO

Import RDO

ClientApplicationApplication

on Mobile Host

Client

QPRC Log

Object Cache

Access Manager

Figure 20. Rover’s relocatable dynamic object (RDO) architecture.



the network scheduler. Each machinehas a local Rover access manager whichis responsible for handling all interac-tions between client-side and server-side applications and among client-sideapplications. The access manager ser-vices requests for objects (RDOs), medi-ates network access, logs modificationsto objects, and, on the clients’ side, man-ages the object cache. Client-side appli-cations communicate with the accessmanager to import objects from serversand cache them locally. Server-side ap-plications are invoked by the accessmanager to handle requests from client-side applications. Applications invokethe methods provided by the objectsand, using the access manager, makethe changes globally visible by export-ing them back to the servers.

Within the access manager, RDOs areimported into the object cache whileQRPCs are exported to the operationlog. The access manager routes invoca-tions and responses between applica-tions, the cache, and the operation log.The log is drained by the networkscheduler, which mediates between thevarious communication protocols andnetwork interfaces.

The object cache provides stable stor-age for local copies of imported objects.The object cache consists of a local pri-vate cache located within the applica-tion’s address space and a global sharedcache located within the access manag-er’s address space. Client-side applica-tions do not usually interact directly

with the object cache. When a client-side application issues an import or ex-port operation, the Toolkit satisfies therequest depending on whether the ob-ject is found in a local cache and on theconsistency option specified for the ob-ject.

Once an object has been imported intothe client-side application’s local ad-dress space, method invocations withoutside effects are serviced locally by theobject. At the application’s discretion,method invocations with side effectsmay also be processed locally, insertingtentative data into the object cache. Op-erations with side effects also insert aQRPC into a stable operation log lo-cated at the client. Each insert is asynchronous action. Support for inter-mittent network connectivity is accom-plished by allowing the log to be incre-mentally flushed back to the server.Thus, as network connectivity comesand goes, the client will make progresstowards reaching a consistent state.

The network scheduler contributes tolog transmission optimization by group-ing operations destined to the sameserver for transmission and selectingthe appropriate transport protocol andmedium over which to send them. Roveris capable of using a variety of networktransports. Rover supports both connec-tion-based protocols (e.g., HTTP overTCP/IP networks) and connection-lessprotocols (e.g., SMTP over IP or non-IPnetworks). The network scheduler lever-ages the queuing of QRPCs performed

EngineSearch

proxyWWW

FilesysCalendar

FilesysEmailSearch

BrowserWWWCalendar

GUIEmail

Network

ServerMobile Host

ObjectCache

AccessManager

OperationLog

Network

Scheduler

OperationLog

Scheduler

Network

ManagerAccess

ObjectCache

AccessManager

OperationLog

Network

Scheduler

OperationLog

Scheduler

Network

ManagerAccess

Figure 21. Rover component architecture.



by the log to gain transmission effi-ciency.

5.3.2 Constructing Mobile Applica-tions Using Rover. There are severalsteps involved in porting an existingapplication to Rover or creating a newRover-based application. Each step re-quires the application developer tomake several implementation choices.The first step is to split the applicationinto components and identify whichcomponents should be present on eachside of the network link. The divisionwill be mostly static because most of thefile system components will remain onthe server and most of the GUI compo-nents will remain on the client. How-ever, those components that are depen-dent upon the computing environment(network or computational resources) orare infrequently used may be dynami-cally relocated.

Once the application has been splitinto components, the next step is toappropriately encapsulate the applica-tion’s state within objects that can bereplicated and sent to multiple clients.In migrating to the mobile environment,the application’s reading of files is re-placed by importing of objects, and itswriting of files is replaced by exportingof changes to objects. The file systeminterface still exists in the server-side ofthe application. However, inserted be-tween the two halves of the applicationis an object layer.

One of the primary purposes of theobject layer is to provide a means ofreducing the number of network mes-sages that must be sent between theclient and the server; this is done bymigrating the computation.

The next step is to add support forinteracting with the environment. Forexample, in an e-mail message, one ofthe important pieces of message meta-data that a folder object contains is themessage size and the size of any attach-ments. This information can be used bythe application and conveyed to the userto allow useful decisions to be made.Support for prefetching is another envi-

ronment interaction issue. Also, the ap-plication developer must decide whichmechanisms to use for notifying users ofthe status of displayed data.

The final and important step is theaddition of application-specific conflictresolution procedures. For most station-ary environments, conflicts are infre-quent. For the mobile environment,they will be more common. Applicationdevelopers can leverage the additionalsemantic information that is availablewith Rover’s operation-based (instead ofvalue-based) approach to object updat-ing.

The programming interface betweenRover and its client applications con-tains four primary functions: create ses-sion, import, export, and invoke. Clientapplications call create session oncewith authentication information to setup a connection with the local accessmanager and receive a session identi-fier. The authentication information isused by the access manager to authenti-cate the client requests sent to Roverservers.

To import an object, an applicationcalls import and provides the object’sunique identifier, the session identifier,a callback, and arguments. In addition,the application specifies a priority thatis used by the network scheduler toreorder QRPCs. The import function im-mediately returns a promise to the ap-plication. The application can then waiton this promise or continue execution.Rover transparently queues QRPCs foreach import operation in the stable log.When the requested object is receivedby the access manager, the access man-ager updates the promise with the re-turned information. In addition, if acallback was specified, the access man-ager invokes it.

Once an object is imported, an appli-cation can invoke methods on it to readand/or change it. Applications exporteach local change to an object back tothe servers by calling the export opera-tion and providing the object’s uniqueidentifier, the session identifier, a call-back, and arguments. Like import, ex-



port immediately returns a promise.When the access manager receives re-sponses to export, it updates the af-fected promises and invokes any appli-cation-specified callbacks.

5.3.3 Rover Applications. Two mo-bile-transparent applications that havebeen implemented using the Rover Tool-kit are Rover NNTP proxy, a USENETreader proxy, and Rover HTTP proxy, aproxy for Web browsers. Mobile-awareapplications implemented using Roverare Rover Exmh, an e-mail browser;Rover Webcal, a distributed calendartool; Rover Irolo, a graphical rolodextool; and Rover Stock Market Watcher,a tool that obtains stock quotes.

Two of the mobile-aware applicationsare based upon existing UNIX applica-tions. Rover Exmh is a port of BrentWelch’s Exmh Tcl/Tk-based e-mailbrowser. Rover Webcal is a port of Ical,a Tcl/Tk and C11 based distributedcalendar and scheduling program writ-ten by Sanjay Ghemawat. Rover Iroloand the Rover Stock Market Watcherwere built from scratch.

The Rover HTTP and NNTP proxiesdemonstrate how Rover mobile-awareproxies support existing applications(e.g., Netscape and xrn) without modifi-cation (i.e., mobile-transparent applica-tions).

Rover NNTP proxy: Using the RoverNNTP proxy, users can read USENETnews with standard news readers whiledisconnected and receive news updateseven over very slow links. Whereasmost NNTP servers download and storeall available news, the Rover proxycache is filled on a demand-driven basis.When a user begins reading a news-group, the NNTP proxy loads the head-ers for that newsgroup as a single RDOwhile articles are prefetched in thebackground. As the user’s news readerrequests the header of each article, theNNTP proxy provides them by using thelocal newsgroup RDO. As new articlesarrive at the server, the server-side ofthe proxy constructs operations to up-

date the newsgroup-header object.Thus, when a news reader performs thecommon operation of rereading theheaders in a newsgroup, the NNTPproxy can service the request with min-imal communication over the slow link.

Rover HTTP proxy: This applicationallows users of existing Web browsers to“click ahead” of the arrived data by re-questing multiple new documents beforeearlier requests have been satisfied.The proxy intercepts all web requestsand, if the requested item is not locallycached, returns a null response to thebrowser and enqueues the request inthe operation log. When a connectionbecomes available, the page is automat-ically requested. In the meantime, theuser can continue to browse alreadyavailable pages and issue additional re-quests for pages without waiting. Thegranularity of RDOs is individual pagesand images. The client and server coop-erate in prefetching. The client specifiesthe depth of prefetching for pages whilethe server automatically prefetches in-lined images. The proxy uses a separatewindow (from the browser) to displaythe status of a page (loaded or pending).If an uncached file is requested and thenetwork is unavailable, an entry isadded to the window. As pages arrive,the window is updated to reflect thechanges. This window exposes the ob-ject cache and operations log directly tothe user and allows the user limitedcontrol over them.

Rover Exmh: Rover Exmh uses threetypes of RDOs: mail messages, mailfolders, and lists of mail folders. Byusing this level of granularity, manyuser requests can be handled locallywithout any network traffic. Upon start-up, Rover Exmh prefetches the list ofmail folders, the mail folders the userhas recently visited, and the messagesin the user’s inbox folder. Alternatively,using a finer-level granularity (e.g.,header and message body) would allowfor more prefetching, but could delayservicing of user requests (especially



during periods of disconnection). Usinga larger granularity (e.g., entire folders)would seriously affect usability and re-sponse time for slow links.

Some computation can be migrated toservers. For example, instead of per-forming a glimpse search of mail folderslocally at the client (and thus having toimport the index across a potentiallylow bandwidth link), the client can con-struct a query request RDO and send itto the server.

The GUI indicates that an operationis tentative through color coding. Con-flict detection is based upon a log ofchanges to RDOs; this allows the serverto detect and resolve a conflict, such asone user adding a message to a folderand another user deleting it. Unresolv-able conflicts are reflected back to theuser.

Rover Webcal: This distributed calen-dar tool uses two types of RDOs: items(appointments, daily to-do lists, anddaily reminders) and calendars (lists ofitems). At this level of granularity, theclient can fetch calendars and thenprefetch items using a variety of strate-gies (e.g., plus or minus one week, amonth at a time, etc.).

Rover Webcal uses color coding to aidthe user in identifying those objectsthat have been locally modified but notyet propagated to a server. Conflict de-tection is based upon a log of changes toRDOs; this allows the server to detectand resolve a conflict, such as one useradding an item to a calendar and an-other user deleting it.

Rover Irolo: This graphical rolodexapplication uses two types of RDOs: en-tries and indices (lists of entries). TheGUI displays the last time an entry wasupdated and indicates whether the itemis committed or tentative. Conflict de-tection is based upon a log of changes toRDOs; this allows the server to detectand resolve a conflict such as one useradding an entry to an index and anotheruser deleting it.

Rover Stock Market Watcher: This ap-plication uses both computation migra-tion and fault-tolerance techniques. Theclient constructs RDOs for stocks thatare to be monitored and sends them tothe server. The server uses fault-toler-ant techniques to store the real-timeinformation retrieved from stock tickerservices.

5.4 Summary

Tables I, II, and III summarize thethree systems, Bayou, Odyssey, andRover, used as case studies in this sec-tion. The tables highlight the applica-tions each of these systems supports,and the mobile client-server computingstrategies and techniques each of themhas implemented.

6. CONCLUSION

With advances in wireless data telecom-munications and portable computers,nomadic users will soon enjoy virtuallyunlimited access to information and ser-vices anytime and anywhere. There are,

Table I. Summary of the Bayou system

System BayouApplications non-real-time collaborative applications: meeting room scheduler and bibliographic

database, appointment calendars, evolving design documents, news bulletin boardsAdaptation application-specific adaptation to disconnection & intermittent connectivity;

applications are permitted to make trade-off of replicated data consistency &availability by using individually selectable session guarantees

Model collaborative and flexible group-based client-server Architecture and full (ordisconnected) client architecture

Mobile Data system support for detection of update conflicts, application-specific resolution ofupdate conflicts, eventual replica convergence through a peer-wise anti-entropyprocess, and per-client consistency guarantees



however, obstacles and limitationsinherent in the wireless environment.The unpredictable mobility of the useradds a great deal of complexity to theproblem. Such obstacles render the tra-ditional approach to designing andimplementing client-server applicationsinsufficient in meeting nomadic users’expectations.

Using assumptions linked to secondgeneration wireless networks and toless than ideal mobile computers (gen-eral purpose portable computers withlimited resources), researchers realizedthat either application or system adap-tation is a key requirement in any mo-bile computing system. Researchers alsorealized that they must identify andsystematically eliminate the limitationsof this new environment through vari-ous optimizations.

This survey explores issues related tothe development and deployment ofsuch adaptive mobile applications. Inparticular, it focuses on new designsand computing paradigms for mobile cli-ent-server applications. It also reviewssystem architecture that supports suchapplications. The survey identifies keycharacteristics that distinguish mobileclient-server computing from its tradi-tional counterpart. The survey also ex-amines how these computing character-istics impact information services and

applications and discusses new comput-ing paradigms that are required to dealwith these impacts. One contribution ofthis survey is a categorization of emerg-ing computing paradigms for mobile cli-ent-server applications. The mobile-aware adaptation, extended client-servermodel, and mobile data access are threecategories that are explained and ana-lyzed. For each category, examples thatshow the related design and implemen-tation issues are detailed. The surveyalso provides a comparative reviewof three major and ongoing researchprototypes of mobile client-server infor-mation systems, namely, Bayou fromXerox Labs, Odyssey from CMU, andRover from MIT. These prototypes dem-onstrate the applications of new com-puting paradigms in building adaptivemobile client-server systems and appli-cations.

Mobile computing (including mobileclient-server information access) is arapidly changing research field that de-pends on a rapidly evolving set of tech-nologies. The advent of the so-calledthird generation wireless communica-tion systems, such as UMTS, is an indi-cation of the importance of research inthis area. Researchers, however, shouldmonitor these advances closely andshould adapt and direct their researchbased on the parameters of the latest

Table II. Summary of the Odyssey system

System OdysseyApplications file system access, video playing, and Web browsingAdaptation client-based application adaptation with the system support that provides resource

monitoring, notifies applications of resource changes, and enforces resourceallocation decisions

Model classic client-server architectureMobile Data client pull based data (distilled copies) delivery

Table III. Summary of the Rover system

System RoverApplications e-mail, appointments, todo lists, reminders, calendars; Web pages and imagesAdaptation client-server application adaptation with the use of Rover Toolkits that deal with

intermittent and low-bandwidth connection and resource-poor clients; application-transparent adaptation by using Rover proxies

Model flexible client-server architecture with the use of RDOsMobile Data asynchronous RDOs pull (import) and push (export)



technology. This is important becausesome of the strong assumptions regard-ing the limitations of the wireless net-work or the mobile computer are beingrelaxed or nullified by newer technolog-ical developments.

Many problems still remain to be un-derstood and solved. At this time, it isintricately difficult to quantitativelyevaluate and compare the various pro-posed models and techniques because ofthe lack of available application experi-ences and samples. Experimentationwith these models should be the criticalnext step in mobile computing research.We hope that this comprehensive re-view will help enhance the understand-ing of the opportunities and limitationsof mobile client-server computing. Wealso hope that the review substantiatesthe importance of recognizing and un-derstanding emerging technologies inshaping the future directions of re-search in this area.

REFERENCES

ACHARYA, S., ALONSO, R., FRANKLIN, M., ANDZDONIK, S. 1995. Broadcast disks: Datamanagement for asymmetric communicationenvironments. In Proceedings of the 1995ACM SIGMOD International Conference onManagement of Data (SIGMOD ’95, San Jose,CA, May 23–25, 1995), M. Carey and D.Schneider, Eds. ACM Press, New York, NY,199–210.

ACHARYA, S., FRANKLIN, M., AND ZDONIK, S.1997. Balancing push and pull for databroadcast. SIGMOD Rec. 26, 2, 183–194.

BARBARA, D. AND IMIELINSKI, T. 1994. Sleepersand workaholics: Caching strategies in mobileenvironments. In Proceedings of the 1994ACM Conference on SIGMOD (Minneapolis,MN, May). ACM Press, New York, NY, 1–12.

BARTLETT, J. 1994. W4-The wireless world wideweb.

BHARGHAVAN, V. AND GUPTA, V. 1997. A frame-work for application adaptation in mobilecomputing environments. In Proceedings ofthe 21st International Computer Software andApplications Conference (COMPSAC ’97).IEEE Computer Society, New York, NY, 573–579.

BREWER, E., KATZ, R., CHAWATHE, Y., GRIBBLE, S.,HODES, T., NGUYEN, G., STEMM, M., HENDER-SON, T., AMIR, E., BALAKRISHNAN, H., FOX, A.,PADMANABHAN, V., AND SESHAN, S. 1998. Anetwork architecture for heterogeneous mo-

bile computing. IEEE Personal Commun. 5,5, 8–24.

BROOKS, C., MAZER, M., MEEKS, S., AND MILLER, J.1996. Application-specific proxy servers asHTTP stream transducers. In Proceedings ofthe 4th International World Wide Web Confer-ence (WWW-4).

CHANG, H., TAIT, C., COHEN, N., SHAPIRO, M., MAS-TRIANNI, S., FLOYD, R., HOUSEL, B., ANDLINDQUIST, D. 1997. Web browsing in awireless environment: Disconnected andasynchronous operation in ARTour Web Ex-press. In Proceedings of the 3rd AnnualACM/IEEE International Conference on Mo-bile Computing and Networking (MOBICOM’97, Budapest, Hungary, Sept. 26–30, 1997),L. Pap, K. Sohraby, D. B. Johnson, and C.Rose, Eds. ACM Press, New York, NY, 260–269.

CITRIX, 1998. http://www.citrix.com.COMPACTHTML, 1998. http://www.w3.org/sub-

mission/1998/04/.DAVIS, N., FRIDAY, A., WADE, S., AND BLAIR,

G. 1998. L2imbo: A distributed systemsplatform for mobile computing. Mob. Netw.Appl. 3, 2, 143–156.

DEMERS, A., PETERSEN, K., SPREITZER, M., TERRY,D., THEIMER, M., AND WELCH, B. 1994. TheBayou architecture: Support for data sharingamong mobile users. In Proceedings of theIEEE Workshop on Mobile Computing Sys-tems and Applications (Santa Cruz,CA). IEEE Press, Piscataway, NJ.

DURAN, J. AND LAUBACH, A. 1999. Virtual per-sonal computers and the portable network.In Proceedings of the IEEE Conference onPerformance, Communication, and Comput-ing (Phoenix, AZ). IEEE Computer SocietyPress, Los Alamitos, CA.

ELMAGARMID, A., JING, J., AND BUKHRES, O.1995. An efficient and reliable reservationalgorithm for mobile transactions. In Pro-ceedings of the 1995 International Conferenceon Information and Knowledge Management(CIKM, Baltimore, MD, Nov. 28–Dec. 2,1995), N. Pissinou, A. Silberschatz, E. K.Park, K. Makki, and C. Nicholas, Eds. ACMPress, New York, NY, 90–95.

FOX, A., GRIBBLE, S., BREWER, E., AND AMIR, E.1996. Adapting to network and client varia-tion via on-demand, dynamic distillation. InProceedings of the 7th International Confer-ence on Architectural Support for Program-ming Languages and Operating Systems (AS-PLOS-VII, Cambridge, MA, Oct. 1–5, 1996),B. Dally and S. Eggets, Eds. ACM Press,New York, NY.

GENERAL MAGIC, INC., 1997. Odyssey ProductInformation. http://www.genmagic.com/agents/odyssey.html.

GRAY, R. 1995. AgentTcl: A transportable agentsystem. In Proceedings of the CIKM Work-shop on Intelligent Information Agents.

HDML, 1997. http://www.uplanet.com.



HEIDEMANN, J., PAGE, T., GUY, R., AND POPEK, G.1992. Primarily disconnected operation: Ex-perience with Ficus. In Proceedings of the2nd Workshop on Management of ReplicatedData (Monterey, CA, Nov.).

HERMAN, G., GOPAL, G., LEE, K., AND WEINRIB, A.1987. Datacycle architecture for very highthroughput database systems. In Proceed-ings of the ACM SIGMOD Annual Conferenceon Management of Data (SIGMOD ’87, SanFrancisco, CA, May 27-29, 1987), U. Dayal,Ed. ACM Press, New York, NY.

HONEYMAN, P., HUSTON, L., REES, J., AND BACH-MAN, D. 1992. The LITTLE WORK project.In Proceedings of the 3rd Workshop on Work-station Operating Systems (Key Biscayne,FL).

HOUSEL, B. C. AND LINDQUIST, D. B. 1996.WebExpress: A system for optimizing Webbrowsing in a wireless environment. In Pro-ceedings of the 2nd Annual International Con-ference on Mobile Computing and Networking(MOBICOM ’96, Rye, New York, Nov. 10–12,1996), H. Ahmadi, R. H. Katz, I. F. Akyildz,and Z. J. Haas, Eds. ACM Press, New York,NY, 108–116.

IBM TOKYO RESEARCH LABS, 1997. The AgletWorkbench: Programming Mobile Agents inJava. http://www.trl.ibm.co.jp/aglets/.

IMIELINSKI, T. AND BADRINATH, B. R. 1994.Mobile wireless computing: Challenges indata management. Commun. ACM 37, 10(Oct. 1994), 18–28.

IMIELINSKI, T., VISHWANATH, S., AND BADRINATH, B.1994. Energy efficient indexing on air. InProceedings of the 1994 ACM SIGMOD Inter-national Conference on Management of Data(SIGMOD ’94, Minneapolis, MN, May 24–27,1994), R. T. Snodgrass and M. Winslett,Eds. ACM Press, New York, NY.

IMIELINSKI, T., VISWANATHAN, S., AND BADRINATH,B. R. 1994. Power efficient filtering of dataon air. In Proceedings of the Fourth Interna-tional Conference on Extending DatabaseTechnology: Advances in Database Technology(EDBT ’94, Cambridge, UK, Mar. 28–31,1994), M. Jarke, J. Bubenko, and K. Jeffery,Eds. Proceedings of the Second Symposiumon Advances in Spatial Databases, vol.779. Springer-Verlag, New York, NY, 245–258.

JAIN, R. AND KRISHNAKUMAR, N. 1994. Servicehandoffs and virtual mobility for delivery ofpersonal information services to mobile users.Technical Report TM-24696. Bellcore, NJ.

JING, J., ELMAGARMID, A., HELAL, A. S., ANDALONSO, R. 1997. Bit-sequences: An adap-tive cache invalidation method in mobile cli-ent/server environments. Mob. Netw. Appl.2, 2, 115–127.

JOSEPH, A. D. AND KAASHOEK, M. F. 1997.Building reliable mobile-aware applicationsusing the Rover toolkit. Wireless Networks 3,5, 405–419.

JOSEPH, A. D., TAUBER, J. A., AND KAASHOEK, M. F.1997. Mobile computing with the Rover tool-kit. IEEE Trans. Comput. 46, 3, 337–352.

KATZ, R. 1994. Adaptation and mobility inwireless information systems. IEEE Per-sonal Commun. 1, 1, 6–17.

KISTLER, J. J. AND SATYANARAYANAN, M. 1992.Disconnected operation in the Coda File Sys-tem. ACM Trans. Comput. Syst. 10, 1 (Feb.1992), 3–25.

KOJO, M., RAATIKAINEN, K., AND ALANKO,T. 1994. Connecting mobile workstationsto the internet over a digital cellular tele-phone network. In Proceedings of the Mobi-data Workshop. Rutgers University Press,New Brunswick, NJ.

KRISHNAKUMAR, N. AND JAIN, R. 1994. Protocolsfor maintaining inventory databases and userservice profiles in mobile sales applications.In Proceedings of the Mobidata Work-shop. Rutgers University Press, New Brun-swick, NJ.

KUENNING, G. H. AND POPEK, G. J. 1997.Automated hoarding for mobile comput-ers. ACM SIGOPS Oper. Syst. Rev. 31, 5,264–275.

KUMAR, P. AND SATYANARAYANAN, M. 1993.Supporting application-specific resolution inan optimistically replicated file system. InProceedings of the 4th Workshop on Worksta-tion Operating Systems (Napa, CA, Oct.).

LE, M., SESHAN, S., BURGHARDT, F., AND RABAEY, J.1994. Software architecture of the InfoPadsystem. In Proceedings of the MobidataWorkshop on Mobile and Wireless InformationSystems (Rutgers, NJ, Nov.).

MUMMERT, L. AND SATYANARAYANAN, M. 1994.Large granularity cache coherence in the codafile system. In Proceedings of the USENIXSummer Conference (Boston, Mass.). USE-NIX Assoc., Berkeley, CA.

NARAYANASWAMY, S. ET AL., 1996. Applicationand network support for InfoPad. IEEE Per-sonal Commun. 3, 2.

NOBLE, B., PRICE, M., AND SATYANARAYANAN,M. 1995. A programming interface for ap-plication-aware adaptation in mobile comput-ing. In Proceedings of the 2nd USENIX Sym-posium on Mobile and Location-IndependentComputing.

NOBLE, B. D., SATYANARAYANAN, M., NARAYANAN,D., TILTON, J. E., FLINN, J., AND WALKER, K.R. 1997. Agile application-aware adapta-tion for mobility. ACM SIGOPS Oper. Syst.Rev. 31, 5, 276–287.

PITOURA, E. AND SAMARAS, S. 1998. Data Man-agement for Mobile Computing. Kluwer Aca-demic Publishers, Hingham, MA.

SATYANARAYANAN, M. 1996. Accessing informa-tion on demand at any location. mobile infor-mation access. IEEE Personal Commun. 3,1, 26–33.

SATYANARAYANAN, M., KISTLER, J. J., KUMAR, P.,OKASAKI, M. E., SIEGEL, E. H., AND STEERE, D.



C. 1990. Coda: A highly available file sys-tem for a distributed workstation environ-ment. IEEE Trans. Comput. 39, 4 (Apr.1990), 447–459.

SATYANARAYANAN, M., NOBLE, B., KUMAR, P., AND

PRICE, M. 1995. Application-aware adapta-tion for mobile computing. ACM SIGOPSOper. Syst. Rev. 29, 1 (Jan. 1995), 52–55.

SU, C.-J. AND TASSIULAS, L. 1998. Joint broad-cast scheduling and user’s cache managementfor efficient information delivery. In Thefourth annual ACM/IEEE international con-ference on Mobile computing and networking(MOBICOM ’98, Dallas, TX, Oct. 25–30,1998), W. P. Osborne and D. Moghe,Eds. ACM Press, New York, NY, 33–42.

TAIT, C. AND DUCHAMP, D. 1991. Service inter-face and replica consistency algorithm for mo-bile file system clients. In Proceedings of theFirst International Conference on Parallel andDistributed Information Systems (MiamiBeach, Florida). 190–197.

TAIT, C. D. AND DUCHAMP, D. 1992. An efficientvariable consistency replicated file service.In Proceedings of the USENIX File SystemsWorkshop. USENIX Assoc., Berkeley, CA,111–126.

TERRY, D., DEMERS, A., PETERSEN, K., SPREITZER,M., THEIMER, M., AND WELCH, B. 1994.Session guarantees for weakly consistent rep-licated data. In Proceedings of the 3rd Inter-national Conference on Parallel and Distrib-uted Information Systems (PDIS, Austin, TX,Sept.).

TERRY, D. B., THEIMER, M. M., PETERSEN, K., DEM-ERS, A. J., SPREITZER, M. J., AND HAUSER, C.H. 1995. Managing update conflicts inBayou, a weakly connected replicated storagesystem. ACM SIGOPS Oper. Syst. Rev. 29, 5(Dec.), 172–182.

VISHWANATH, S. AND IMIELINSKI, T. 1995.Pyramid broadcasting for video on demandservice. In Proceedings of the IEEE Multime-dia Computing and Networks Conference (SanJose, Calif.). IEEE Computer Society Press,Los Alamitos, CA.

WAP, 1996. http://www.wapforum.org.WELLING, G. AND BADRINATH, B. R. 1998. An

architecture for exporting environmentawareness to mobile computing applications.IEEE Trans. Softw. Eng. 24, 5, 391–400.

ZENEL, B. AND DUCHAMP, D. 1997. General pur-pose proxies: Solved and unsolved problems.In Proceedings of the 6th Workshop on HotTopics in Operating Systems. 87–92.

Received: June 1996; revised: March 1998; accepted: December 1998



client-server computing in mobile environments · 2015-06-16 · client-server computing in mobile...

Documents