fundamental challenges in mobile computing

8/2/2019 Fundamental Challenges in Mobile Computing

1/7

Fundamental Challenges in Mobile ComputingM. Satyanarayanan

School of Computer ScienceCarnegie Mellon University

AbstractThis paper is an answer to the question What is unique and conceptuntly different aboutmobile computing? The paper begins by describing a set of constraints intr insic to mobilecomputing, and examining the impact of these constraints on the design of distributed systems.Next, it summarizes the key results of the Coda and Odyssey systems. Finally, it describes theresearch opportunities in five important topics relevant to mobile computing: caching metrics,semantic callbacks and validators, resource revocation, analysis of adaptation, and globalestimation from local observations.

1. IntroductionWhat is really different about mobile computing? The

computers are smaller and bits travel by wireless ratherthan Ethernet. How can this possibly make any difference?Isnt a mobile system merely a special case of a distributedsystem? Are there any new and deep issues to beinvestigated, or is mobile computing just the latest fad?

This paper is my attempt to answer these questions. Thepaper is in three parts: a characterization of the essence ofmobile computing; a brief summary of results obtained bymy research group in the context of the Coda and Odysseysystems; and a guided tour of fertile research topicsawaiting investigation. Think of this paper as a report fromthe front by an implementor of mobile information systemsto more theoretically-incl ined computers scientists.1.1. Constraints of Mobility

Mobile computing is characterized by four constraints:q Mobile elements are resource-poor relative to static

elements.For a given cost and level of technology,considerations of weight, power, size andergonomics will exact a penalty in computationalresources such as processor speed, memory size,and disk capacity. While mobile elements willimprove in absolute ability, they will always beresource-poor relative to static elements.

This research was supported by the Air Force Materiel Command(AFMC) and ARPA under contract number F196828-93-C-0193.Additional support was provided by the IBM Corp. and Intel Corp. Theviews and conclusions contained here are those of the authors and shouldnot be interpreted as necessarily representing the official policies orendorsements, either express or implied, of AFMC, ARPA, IBM, Intel,CMU, or the U.S. Government .

Permission to make digitalhsrd copies of all or part of ttds material forpereorset or ctaaaroom use is granted without fee provided that the copiesare not made or dktributcd for profit or commercial advantage, the copy-right notice, the title of the publication and ita date appear, and notice isgiven that copyright is by pertnisaion of the ACM, JIW. To copy otherwiee.to rqmbtiah, to pmet on servers or to redhtribute to Ihta, requima epaaificperrnisaion and/or fee.PODC%, Philttdelphia PA, USAe 1996 ACM O-89791-800W96105. .$3.50

. Mobility is inherently hazardous.A Wall Street stockbroker is moremugged on the streets of Manhattan

likely to beand have his

lap;;p stolen than to have his workstation in alocked office be physically subverted. In addition tosecurity concerns, portable computers are morevulnerable to loss or damage.

q Mobile connectivi~ is highly variable inperformance and reliability.Some buildings may offer reliable, high-bandwidthwireless connectivity while others may only offerlow-bandwidth connectivity. Outdoors, a mobileclient may have to rely on a low-bandwidth wirelessnetwork with gaps in coverage.

q Mobile elements rely on afinite energy source.While battexy technology will undoubtedly improveover time, the need to be sensitive to powerconsumption will not diminish. Concern for powerconsumption must span many levels of hardwareand software to be fully effective.

These constraints are not artifacts of current technology,but are intrinsic to mobility. Together, they complicate thedesign of mobile information systems and require us torethink traditional approaches to information access.1.2. The Need for Adaptation

Mobility exacerbates the tension between autonomy andinterdependence that is characteristic of all distributedsystems. The relative resource poverty of mobile elementsas well as their lower trust and robustness argues forreliance on static servers. But the need to cope withunreliable and low-performance networks, as well as theneed to be sensitive to power consumption argues for self-reliance.

Any viable approach to mobile computing must strike abalance between these competing concerns. This balancecannot be a static one; as the circumstances of a mobileclient change, it must react and dynamically reassign theresponsibilities of client and server. In other words, mobileclients must be adaptive.

1


2/7

1.3. Taxonomy of Adaptation StrategiesThe range of strategies for adaptation is delimited by two

extremes, as shown in Figure 1. At one extreme,adaptation is entirely the responsibility of individualapplications. While this laissez-faire approach avoids theneed for system support, it lacks a central arbitrator toresolve incompatible resource demands of differentapplications and to enforce limits on resource usage. Italso makes applications more difficult to write, and fails toamortize the development cost of support for adaptation.

Application-aware

~

Laisaez-fsire Application-transparent(no system support) (no changss to appkabons)

Figure 1: Range of Adaptation StrategiesThe other extreme of application-transparent adaptation

places entire responsibility for adaptation on the system.This approach is attractive because it is backwardcompatible with existing applications: they continue towork when mobile without any modifications. The systemprovides the focal point for resource arbitration andcontrol. The drawback of this approach is that there maysituations where the adaptation performed by the system isinadequate or even counterproductive.

Between these two extremes lies a spectrum ofpossibilities that we collectively refer to asapplication-aware adaptation. By supporting acollaborative partnership between applications and thesystem, this approach permits applications to determinehow best to adapt, but preserves the ability of the system tomonitor resources and enforce allocation decisions.1.4. The Extended Client-Server ModelAnother way to characterize the impact of mobilecomputing constraints is to examine their effect on theclassic client-server model. In this model, a small numberof trusted server sites constitute the true home of data.Efficient and safe access to this data is possible from amuch larger number of untrusted client sites. Techniquessuch as caching and read-ahead can be used to providegood performance, while end-to-end authentication andencrypted transmission can be used to preserve security.

This model has proved to be especially valuable forscalability [16]. In effect, the client-server modeldecomposes a large distributed system into a small nucleusthat changes relatively slowly, and a much larger and lessstatic periphery of clients. From the perspectives ofsecurity and system administration, the scale of the systemappears to be that of the nucleus. But from the perspectivesof performance and availability, a user at the peripheryreceives almost standalone service.

Local RemoteFigure 2: Temporary Blurring of Roles

Coping with the constraints of mobility requires us torethink this model. The distinction between clients andservers may have to be temporarily blurred, resulting in theextended client-server model shown in Figure 2. Theresource limitations of clients may require certainoperations normally performed on clients to sometimes beperformed on resource-rich servers. Conversely, the needto cope with uncertain connectivity requires clients tosometimes emulate the functions of a server. These are, ofcourse, short-term deviations from the classic client-servermodel for purposes of performance and availability. Fromthe Ionger-term perspective of system administration andsecurity, the roles of servers and clients remain unchanged.2. Summary of Coda and Odyssey Results

We have been exploring application-transparentadaptation since about 1990. Our research vehicle has beenthe Coda File System, a descendant of AFS [2]. Coda hasbeen in active use for five years, and has proved to be avaluable testbed [13]. Coda clients are in regular use overa wide range of networks such as 10 Nlbls Ethernet, 2 Mblsradio, and 9600 baud modems.

Since the research contributions of Coda have alreadybeen extensively documented in the literature, we onlyprovide a high-level summary of the key results here:Disconnected operation

Coda has demonstrated that disconnected operation isfeasible, effective, and usable in a distributed Unixfile system [3, 4, 17]. The key mechanims forsupporting disconnected operation include hoarding(user-assisted cache management), update loggingwith extensive optimization while disconnected, andreintegration upon reconnection.

Optimistic replicationCoda was one of the earliest systems to demonstratethat an optimistic replica control strategy can be usedfor serious and practical mobile computing [6]. Itincorporates several novel mechanisms to render thisapproach viable. These include log-based directoryresolution [5], application-specific file resolution [7],and mechanisms for conflict detection, containmentand manual repair.

Support for weak connectivityCoda has shown that weak

2

connectivity can be


3/7

exploited to alleviate the limitations of disconnectedoperation [12]. The mechanisms needed toaccomplish this include adaptive transport protocols,a rapid cache validation mechanism, a tricklereintegration mechanism for propagating updates, andmodel-based cache miss handling for usability.

Isolation-only transactionsIn the context of Coda, a new abstraction calledisolation-only transaction has been developed to copewith the detection and handling of read-write conf lictsduring disconnected operation [9]. This abstractionselectively incorporates concepts from databasetransactions, while making minimal demands ofresource-poor mobile clients and preserving upwardcompatibi li ty with Unix applications.

Server replicationCoda has shown how server replication can be used tocomplement disconnected operation [15]. Althoughthis is not particularly relevant to mobility, it is animportant result in distributed systems because itclarifies the relationship between first-class (i.e.,server) replicas and second-class replicas (i.e., clientcaches). It also represents one of the firstdemonstrations of optimistic replication applied to adistributed system with the client-server model.

More recently, we have begun exploration of application-aware adaptation in Odyssey, a platform for mobilecomputing. An preliminary prototype of Odyssey has beenbuilt [14, 18], and a more complete prototype is underdevelopment. The early evidence is promising, but it is fartoo early for definitive results.

3. Fertile Topics for ExplorationWe now turn to the discussion of promising research

topics in mobile computing. By its very nature, this sectionof the paper is highly speculative and will raise far morequestions than it answers. Further, this is a selective list: itis certainly not intended to be complete. Rather, my goal isto give the reader a tantalizing glimpse of the rich problemspace defined by mobile computing.

In choosing the five topics discussed below, I havefollowed two guidelines. First, these problems are morelikely to be solved by rigor and analysis than byimplementation and experience. Second, each of theseproblems is real, not contrived. Good solutions andinsights to these problems will strongly impact the mobilecomputing systems of the future.

Each topic is presented in two parts: a brief discussionthat lays out the problem space of the topic, followed by asample of open questions pertaining to it. Again, my aimin posing these questions is not to be exhaustive but tooffer food for thought.

3.1. Caching MetricsCaching plays a key role in mobile computing because of

its ability to alleviate the performance and availabilitylimitations of weakly-connected and disconnectedoperation. But evaluating alternative caching strategies formobile computing is problematic.

Today, the only metric of cache quality is the miss ratio.The underlying assumption of this metric is that all cachemisses are equivalent (that is, all cache misses exactroughly the same penalty from the user). This assumptionis valid when the cache and primary copies are stronglyconnected, because the performance penalty resulting froma cache miss is small and, to a first approximation,independent of file length. But the assumption is unlikelyto be valid during disconnected or weakly-connectedoperation.

The miss ratio also fails to take into account the timing ofmisses. For example, a user may react differently to acache miss occurring within the first few minutes ofdisconnection than to one occurring near the end of thedisconnection. As another example, the periodic spin-down of disks to save power in mobile computers makes itcheaper to service a certain number of page faults if theyare clustered together than if they are widely spaced.

To be useful, new caching metrics must satisfy twoimportant criteria. First, they should be consistent withqualitative perceptions of performance and availabilityexperienced by users in mobile computing. Second, theyshould be cheap and easy to monitor. The challenge is todevelop such metrics and demonstrate their applicability tomobile computing. Initial work toward this end is beingdone by Ebling [1].3.1.1. Some Open Questions

q What is an appropriate set of caching metrics formobile computing?

. Under what circumstances does one use eachmetric?

. How does one efficiently monitor these metrics?

. What are the implications of these alternativemetrics for caching algorithms?

3.2. Semantic Callbacks and ValidatorsPreserving cache coherence under conditions of weak

connectivity can be expensive. Large communicationlatency increases the cost of validation of cached objects.Intermittent failures increase the frequency of validation,since it must be performed each time communication isrestored. A lazy approach that only validates on demandcould reduce validation frequency; but this approach wouldworsen consistency because it increases the likelihood ofstale objects being accessed while disconnected. The costof cache coherence is exacerbated in systems like Coda that

3


4/7

use anticipatory caching for availability, because thenumber of objects cached (resident set size) is much largerthan the number of objects in current use (working setsize).

The Coda solution is to maintain cache coherence atmultiple levels of granularity and to use callbacks [11].Clients and servers maintain version information onindividual objects as well as entire subtrees of them. Rapidcache validation is possible by comparing version stampson the subtrees. Once established, validity can bemaintained through callbacks. This approach to cachecoherence trades precision of invalidation for speed ofvalidation. It preserves correctness while dramaticallyreducing the cost of cache coherence under conditions ofweak connectivity. Usage measurements from Codaconfirm that these potential gains are indeed achievable inpractice [12].

The idea of maintaining coherence at multiplegranularities can be generalized to a variety of data typesand applications in the following way:

q a client caches data satisfying some predicate Pfrom a server.

. the server remembers a predicate Q that is muchcheaper to compute, and possesses the property Qimplies P. In other words, as long as Q is true, thecached data it corresponds to is guaranteed to bevalid. But if Q is false, nothing can be inferredabout that data.

. On each update, the server re-evalttates Q. If Qbecomes false, the server notifies the client that itscached data might be stale.

. Prior to its next access, the client must contact theserver and obtain fresh data satisfying P.

We refer to Q as a semantic cal lback for P, because theinterpretation of P and Q depends on the specifics of thedata and application. For example, P would be an SQLselect statement if one is caching data from a relationaldatabase. Or it could be a piece of code that performs apattern match for a particular individuals face from adatabase of images. Q must conform to P a simplerselect statement in the first case, and a piece of codethat performs a much less accurate pattern match in thesecond case. In Coda, P corresponds to the version numberof an object being equal to a specific value (x), while Qcorresponds to the version number of the encapsulatingvolume being unchanged since the last time the versionnumber of the object was confirmed to be x.

Semantic validation can be extended to domains beyondmobile computing. It will be especially valuable ingeographically widespread distributed systems, where thetiming difference between local and remote actions is toolarge to ignore even when communication occurs at thespeed of light. The predicate Q in such cases serves as an

inexpensive validator for cached data satisfying somecomplex criteria.

Consider the example of a transcontinental distributedsystem in the United States. Even at the speed of light,communication from one coast to the other takes about 16milliseconds. A round trip RPC will take over 30milliseconds. During this time, a client with a 100 MIPprocessor can execute over 3 million instructions! Sinceprocessor speed can be expected to increase over time, thelost computational opportunity represented by this scenariowill only worsen.

Over time, the synchronous model implicit in the use ofRPC will become increasingly untenable. Eventually, verywide-area distributed systems will have to be structuredaround an asynchronous model. At what scale andtimeframe this shift will occur depends on two factors: thesubstantial y simpler design, implementation, anddebugging inherent in the synchronous model, and theconsiderably higher performance (and hence usability) ofthe asynchronous model.

One promising asynchronous model is obtained bycombining the idea of cheap but conservative validationwith the style of programming characterized by optimisticconcurrency control [8]. The resulting approach bearssome resemblance to the use of hints in distributedsystems [19], and is best illustrated by an example.

Consider remote control of a robot explorer on thesurface of Mars. Since light takes many minutes to travelfrom earth to Mars, and emergencies of various kinds mayarise on Mars, the robot must be capable of reacting on itsown. At the same time, the exploration is to be directedlive by a human controller on earth a classic commandand control problem.

This example characterizes a distributed system in whichcommunication latency is large enough that a synchronousdesign paradigm will not work. The knowledge of therobots status will always be obsolete on earth. But, sinceemergencies are rare, this knowledge will usually differfrom current reality in one of two benign ways. Either thedifferences are in attributes irrelevant to the task at hand, orthe differences can be predicted with adequate accuracy bymethods such as dead reckoning. Suppose the robots stateis P, as characterized in a transmission to earth. Based onsome properties, Q, of this state, a command is issued tothe robot. For this command to be meaningful when itreaches the robot, Q must still be true. This can be verifiedby transmitting Q along with the command, and having therobot validate Q upon receipt. For this approach to befeasible, both transmitting and evaluating Q must be cheap.

There are, of course, numerous detailed questions to beanswered regarding this approach, But it does offer anintriguing way of combining correctness with performancein very wide-area distributed systems.


5/7

3.2.1. Some Open Questions. Under what circumstances are semantic callbacks

most useful? When are they not useful?. What forms can P and Q take for data types and

applications in common use? How does oneestimate their relative costs in those cases?

. Can P and Q really be arbitrary code? Are thererestrictions necessary for efficiency andpracticality?

q How does one derive Q from P quickly? Are thererestrictions on P that make this simpler?

. How does one trade off the relative cost and benefitof P and Q? Is the tradeoff space discrete orcontinuous? Can this tradeoff be made adaptive?

3.3. Algorithms for Resource RevocationApplication-aware adaptation complicates the problem of

resource management. In principle, the system owns allresources. At any time, it may revoke resources that it hastemporarily delegated to an application. Alas, reality isnever that simple. A variety of factors complicate theproblem.

First, some applications are more important than others.Any acceptable revocation strategy must be sensitive tothese differences. Second, the cost of revoking the sameresource may be different to different applications. Forexample, reducing the bandwidth available to oneapplication may result in its substantially increasing theamount of processing it does to compensate. A similarreduction in bandwidth for another application may resultin a much smaller increase in processing. A goodrevocation strategy must take into account these differentialimpacts. Third, there may be dependencies betweenprocesses that should be taken into account duringrevocation. For example, two processes may have aproducer-consumer relationship. Revoking resources fromone process may cause the other to stall. More complexdependencies involving multiple processes are alsopossible. Unless revocation takes these dependencies intoaccount, hazards such as deadlocks may occur.

Revocation of resources from applications is not commonin current systems. Classical operating systems researchhas focused on resource allocation issues rather thanresource revocation. As a result there is currently littlecodified knowledge about safe and efficient techniques forrevocation. This deficiency will have to be remedied asapplication-aware adaptation becomes more widely used.3.3.1. Some open questions

q How does one formulate the resource revocationproblem?

q How does one characterize the differential impact ofrevocation on different applications?

. What strategies does one use if multiple resourcesmust be simultaneously revoked?

. How does one distinguish between resources whoserevocation is easy to recover from and those it isexpensive or impossible to recover born?

. How does one handle deadlocks during revocation?3.4. Analysis of Adaptation

How does one compare the adaptive capabilities of twomobile clients? The primary figure of merit is agility, orthe ability of a client to promptly respond to perturbations.Since it is possible for a client to be more agile with respectto some variables (such as bandwidth) than others (such asbattery power), agility should be viewed as a compositemetric.

A system that is highly agile may suffer from instability.Such a system consumes almost all its resources reacting tominor perturbations, hence performing little usefulcomputation. The ideal mobile client is obviously one thatis highly agile but very stable with respect to all variablesof interest.

Control theory is a domain that might have usefulinsights to offer in refining these ideas and quantifyingthem. Historically, control theory has focused on hardwaresystems. But there is no conceptual reason why it cannotbe extended to software systems. Only carefulinvestigation can tell, of course, whether the relevance isdirect and useful or merely superficial.3.4.1. Some open questions

q What are the right metrics of agility?. Are there systematic techniques to improve the

agility of a system?. How does one decide when a mobile system is

agile enough?q What are the right metrics of system stability?. Can one develop design guidelines to ensure

stability?. Can one analytically derive the agility and stability

properties of an adaptive system without building itfirst?

3.5. Global Estimation from Local ObservationsAdaptation requires a mobile client to sense changes in

its environment, make inferences about the cause of thesechanges, and then react appropriately. These imply theability to make global estimates based on localobservations.

To detect changes, the client must rely on localobservations. For example, it can measure quantities suchas local signal strength, packet rate, average round-triptimes, and dispersion in round-trip times. But interpreting


6/7

these observations is nontrivial. A change in a givenquantity can be due to a multiplicity of non-localphenomena. For example, packet rate will drop due to anoverload on a distant server. But it will also drop whenthere is congestion on an intermediate network segment. Ifan incorrect cause is inferred from an observation, theadaptation performed by the client may be ineffective orcounterproductive.

At present there is no systematic theory to guide globalestimation from local observations. The problem isespecially challenging in the absence of out-of-bandcommunication, because the client cannot use analternative channel to help narrow the diagnosis on themain communication channel.3.5.1. Some Open Qnestions

. Are there systematic ways to do global estimationfrom local estimates?

. Can one bound the error in global estimates?q What is the relationship of global estimation to

agility of adaptation? Can one quantify thisrelationship?

. Can one provide system support to improve globalestimation? For example, do closely-synchronized,low-drift clocks on clients and servers help?

q Can one quantify the benefits of out-of-bandchannels? For example, how much does thepresence of a low-latency, low-bandwidth channelhelp with estimates on a parallel high-latency, high-bandwidth channel?

4. ConclusionThe tension between autonomy and interdependence is

intrinsic to all distributed systems. Mobility exacerbatesthis tension, making it necessary for mobile clients totolerate a far broader range of external conditions than hasbeen necessary hitherto.

Adaptation is the key to mobility. By using localresources to reduce communication and to cope withuncertainty, adaptation insulates users from the vagaries ofmobile environments. Our research is exploring twodifferent approaches to adaptation: application-transparentand application-aware. Our experience with Coda confirmsthat application-transparent adaptation is indeed viable andeffective for a broad range of important applications. Incircumstances where it is inadequate, our initial experiencewith Odyssey suggests that application-aware adaptation isthe appropriate strategy.

In closing, it is worth speculating on the long-termimpact of mobility on distributed systems. In his bookMind Children, my colleague Hans Moravec draws ananalogy between the seminal role of mobility in the

evolution of biological species, and its influence on thecapabilities of computing systems [10]. Although Hanscomments are directed at robotic systems, I believe that hisobservation applies equally well to a much broader class ofdistributed computing systems involving mobile elements.Mobility will influence the evolution of distributed systemsin ways that we can only dimly perceive at the presenttime. In this sense, mobile computing is truly a seminalinfluence on the design of distributed systems.

AcknowledgementsThis paper is the result of many years of interaction andbrainstorming with members of the Coda and Odyssey projects.

These members include Jay Kistler, Puneet Kumar, David Steere,Lily Mummert, Maria Ebling, Hank Mashburn, Brian Noble,Masashi Kudo, Josh Raiff, Qi Lu, Morgan Price, Hiroshi Inamura,Tetsuro Muranaga, Bob Baron, Dushyanth Narayanan, and EricTilton.

I wish to thank Vassos Hadzilacos and Yoram Moses, theprogram chairmen of the Fourteenth and Fifteenth ACMSymposia on Principles of Distributed Computing respectively,for giving me the opportunity to present these thoughts as aninvited speaker at PODC 95 and as an invited paper in theproceedings of PODC 96. I also wish to thank Matt Zekauskasand Brian Noble for their help in reviewing and improving thepresentat ion of the paper.

References[1]

[2]

[3]

[4]

[5]

[6]

Ebling, M.R.Evaluating and Improving the Effect iveness of Caching for

Availability.PhD thesis, Department of Computer Science, Carnegie

Mellon University, 1997 (in preparation).Howard, J.H., Kazar, M. L., Menees, S.G., Nichols, D.A .,Satyanarayanan, M., Sidebotham, R.N., West, M.J.Scale and Performance in a Distributed File System.A(34 Transactions on Computer Systems 6( 1), February.

1988.Kistler, J.J., Satyanarayanan, M.Disconnected Operation in the Coda File System.ACM Transactions on Computer Systems 10(1), February,

1992.Kistler, J.J.Disconnected Operation in a Distr ibuted File System.PhD thesis, Department of Computer Science, Carnegie

Mellon University, May, 1993.Kumar, P., Satyanarayanan, M.Log-Based Directory Resolution in the Coda File System.In Proceedings of the Second International Conference on

Parallel and Distributed Information Systems. SanDiego, CA, January, 1993.Kumar, P.Mitigating the Effects of Optimistic Replication in a

Distributed File System.PhD thesis, School of Computer Science, Carnegie Mellon

University, December, 1994.


7/7

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

Kumar,P.,Satyanarayanan,M.Flexible andSafeResolutionof File Conflicts.In Proceedings of the 1995 USENIX Technical Conference.New Orleans,LA, January,1995.

Kung, H.T., Robinson,J.On Optimistic Methodsfor ConcurrencyControl.ACM Transaction on Database Systems 6(2), June,1981.Lu, Q.,Satyanarayanan,M.Improving DataConsistencyin Mobile ComputingUsingIsolation-Only Transactions.In Proceedings of the Fifth Workshop on Hot Topics in

Operating Systems. OrcasIsland,WA, May, 1995.Moravec,H.Mind Children.HarvardUniversity Press,Cambridge,MA, 1988.Mummert, L.B., Satyanarayanan,M.LargeGranularityCacheCoherencefor IntermittentConnectivity.In Proceedings of the 1994 Summer USENIX Conference.Boston,MA, June,1994.Mummert, L.B., Ebling, M.R., Satyanarayanan,M.Exploiting WeakComectivity for Mobile File Access.In Proceedings of the F~teenth ACM Symposium on

Operating Systems Principles. CopperMountainResort,CO, December,1995.

Noble,B., Satyanarayanan,M.An Empirical Study of a Highly-Available File System.In Proceedings of the 1994 ACM Sigmetrics Conference.Nashville,TN, May, 1994.Noble, B., Price,M., Satyanarayanan,M.A ProgrammingInterfacefor Application-AwareAdaptationin Mobile Computing.Computing Systems 8, Fall, 1995.Satyanarayanan,M., Kktler, J.J.,Kumar,P., Okasaki,M.E., Siegel,E.H., Steere,D.C.Coda A Highly Available File Systemfor a DistributedWorkstationEnvironment.IEEE Transactions on Computers 39(4), April, 1990.Satyanarayanan,M.TheInfluenceof Scaleon DistributedFile SystemDesign.IEEE Transactions on Software Engineering 18(l),

hnuafy, 1992.Satyanarayanan,M., Kistler, J.J.,Mummert,L.B., Ebling,M.R., Kumar,P.,Lu, Q.Experiencewith DisconnectedOperationin aMobileComputingEnvironment.In Proceedings of the 1993 USENIX Symposium on

Mobile and Lacation-hdependent Computing.Cambridge,MA, August, 1993.Steere,D.C., Satyanarayanan,M.Using Dynamic Setsto OvercomeHigh I/O Latencies

During Search.In Proceedings of the F#th Workshop on Hot Topics inOperating Systems. OrcasIsland,WA, May, 1995.

Terry, D.B.CachingHints in Distributed Systems.IEEE Transact ions in Software Engineering SE-13(1),

kUIUZIIY, 1987.

fundamental challenges in mobile computing

Documents