Odyssey   Support for Mobile, Adaptive Applications

Odyssey Support for Mobile, Adaptive Applications PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

2. A Glimpse of the Future. Imagine you are a tourist in Pariswith a wearable computerwireless access to remote servicesunobtrusive heads-up display, microphone, earphonesspeech for computer interactionsonline language translationLet's go . . . . . . . 3. What Makes This Science Fiction?. Lack of hardware?No! We have what we need.Lack of applications?Nope - we have those too.Need a system capable of coping with the problems of mobilityOdyssey to the rescue....

Download Presentation

Odyssey Support for Mobile, Adaptive Applications

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

1. 1 Odyssey – Support for Mobile, Adaptive Applications Examples and some slides from Brian Noble and Kip Walker (contributors to the project)

2. 2 A Glimpse of the Future Imagine you are a tourist in Paris with a wearable computer wireless access to remote services unobtrusive heads-up display, microphone, earphones speech for computer interactions online language translation Let’s go . . . . . .

3. 3

4. 4 Problems with Mobility Mobile elements are resource-poor relative to static elements of same era weight, power, size constraints Mobility leads to communication uncertainty enormous variation in bandwidth & latency intermittent connectivity Power management is a concern actions may have to be slowed or deferred communication costs energy need to rely on resources of remote servers, but may not be able to reach them!

5. 5 Adaptation is Key Highly dynamic environment – adaptation key to good performance Who adapts? System? take advantage of good times Behave ok during bad times CODA This paper: applications also must adapt Change expectations depending on surrounding state End to end argument?

6. 6

7. 7

8. 8

9. 9 Application-Aware Adaptation Application only (laissez faire) What if different applications compete for the resources? OS only (application-transparent) Does not differentiate between applications (student viewing a video of a lecture vs. a video teleconference) Joint responsibility in Odyssey (application-aware) Several ways to divide the functionality – odyssey only one

10. 10 What Knobs Do We Have? Where work gets done let powerful remote servers do the work How snazzy the data is: “Fidelity” degrade data meaningfully before giving to mobile host Fidelity has many dimensions one is universal: consistency others depend on data type movies: frame rate, frame quality geographical databases: feature set, minimum feature size tradeoffs are application-dependent Discussion – anything else?

11. 11

12. 12 Applications Video server offers movie at several levels of fidelity application plays the track that the current bandwidth can support xanim: split into client and server WWW “distillation server” degrades data before shipping to client images can be compressed HTML can be summarized Netscape: client-side proxy + remote distillation server Speech Recognition local/remote/hybrid execution Janus: support remote recognition method, hybrid Other?

13. 13 Odyssey A Platform for adaptive mobile data access

14. 14 Viceroy and Wardens System-level data differentiation through wardens specialized code components (a la device drivers) provides system-level support to manage a data type trusted entities (unlike applications) Wardens subordinate to viceroy single, central component type-independent, system-level support responsible for all resource allocation, arbitration central point of authority and control for Odyssey

15. 15 Odyssey Architecture

16. 16 Resource Negotiation Applications give viceroy a window of tolerance for some resource viceroy monitors resource availability if it leaves window, notifies application via upcall Currently focus only on network bandwidth; what are other resources of interest?

17. 17 Viceroy Monitors resources and notifies applications of any changes in resource levels Does this apply to non-mobile applications? Viceroy acts as a single point of resource control Applications must be able to specify what changes of resources are of interest to them Reporting everything is too expensive since it crosses the OS to user boundary Solution – application specifies a window of tolerance in a resource request system call Viceroy does an upcall if resource availability moves outside the window

18. 18 Wardens Wardens are code components that manage type specific operations Wardens manage communication with the various servers They also offer the fidelity menu to applications Type specific operations can be customized using wardens (e.g., caching) To avoid API explosion, one system call (type-specific operation tsop() is provided Tsop is similar to the un*x ioctl() Can also be used to request type specific operations

19. 19 Operational Model Control loop: Select fidelity (application) Place request (system call) Detect change Notify application

20. 20 Agility An Odyssey client must estimate the quality of network paths used by various applications. Odyssey records: Round-trip time Throughput Odyssey updates its estimates of latency and bandwidth once every half second. Aside, Noble’s group followed up with agility estimation work for ad hoc networks

21. 21 Agility (cont.)

22. 22 Agility (cont.)

23. 23 Stability Pursuing agility while completely sacrificing stability can be counterproductive. Rapidly switching Low-fidelity Variable latency Stability is properly incorporated by individual application. When notifying an application , the viceroy can include information about the expected variance of estimate.

24. 24 Mobile Computing Models Primary source, Jing, Helal and Elmagarmid paper, and slides by Sumi Helal

25. 25 Client/Server Computing

26. 26 Client/Server Design Stateless/stateful client/server design Caching and cache invalidation server invalidates client cache and/or client requests server to validate its cache. file system caching: writes => update propagation Connectionless/connection-oriented design TCP/IP & Interfaces Other issues: multi-threading &deadlocks

27. 27 Fixed Network C/S Assumptions Client Connectivity client is always connected with availability comparable to the server’s. Server can always invalidate the client cache Server Availability & Reliability server is highly available. Reliable if stateless (but state info is exchanged in every C/S interaction), or if implements recovery procedures (may require client availability) Network fast*, reliable*, BER < 10-6, bounded delay variance

28. 28 Taxonomy of C/S Adaptations System-transparent, application-transparent The conventional, “unaware” client/server model System-aware, application-transparent the client/proxy/server model the disconnected operation model System-transparent, application-aware dynamic client/server model the mobile agent (object) model System-aware, application-aware

29. 29 The Unaware Client/Server Model Full client on mobile host and full server on fixed network (SLIP/PPP C/S) Client and Server are not mobility-aware Client caching does not work as the client can be disconnected when the server invalidates the cache Not reliable and of unpredictable performance Requires special cache invalidation algorithms to enable caching despite long client disconnections

30. 30 The Client/Proxy/Server Model Adding mobility-awareness between the client and the server. Client and server are not mobility-aware. Proxy functions as a client to the fixed network server, and as a mobility-aware server to the mobile client Proxy may be placed in the mobile host (Coda’s Venus), or the fixed network, or both (WebExpress) Application- and user-dependent One advantage: enables thin client design for resource-poor mobile computers

31. 31 Thin Client/Server Model Thin client fits in resource poor info appliances Bounded communication Requires at least weak connection CITRIX WinFrame and ICA thin client InfoPad

32. 32 The Disconnected Operation Model Approach I: Provide full client and a thin version of the server on the mobile platform. In addition, needed data is replicated into the mobile platform. Upon reconnection, updated replicas are synchronized with the home server. Conflict resolution strategies are needed (Coda/Venus & Oracle Lite) Approach II: Provide a full client and a mobility agent that intercepts requests to the unreachable server, emulates the server, buffers the requests, and transmit them upon reconnection (Oracle Mobile Agents)

33. 33 The Dynamic Client/Server Model Servers (or their thin versions) dynamically relocate between mobile and fixed hosts. Proxies created and relocated dynamically A spectrum of design and adaptation possibilities Dynamic availability/performance tuning

34. 34 Dynamic Client/Server Model Mobile objects: applications programmed with dynamic object relocation policies for adaptation (Rover’s RDOs) Collaborative Groups: disconnected mobile clients turns into a group of collaborating, mobile servers and clients connected via an ad-hoc net. (Bayou architecture) Virtual Mobility of Servers: servers relocate in the fixed network, near the mobile host, transparently, as the latter moves.

35. 35 The Mobile Agent Model Mobile agent programmed with platform limitations and user profile receives a request; moves into the fixed network near the requested service Mobile agent acts as a client to the server, or invokes a client to the server Based on the nature of the results, experienced communication delays, and programmed knowledge, the mobile agent performs transformations and filtering. Mobile agent returns back to mobile platform, when the client is connected.

36. 36 Mobile Agents in the Mobile Environment

37. 37 File System Proxy in Coda

38. 38 Isolation-Only Transactions in Coda

39. 39 Web Proxy in WebExpress

40. 40 Wireless Web Browser in Mowgli

41. 41 Thin Client InfoPad Architecture

42. 42 Case Studies Bayou Odyssey Rover

43. 43 Case Study1: Bayou Main Features Novel Aspects Bayou architecture Bayou application-specific conflict resolution Bayou replication management

44. 44 Main Features of Bayou Replicated, weakly consistent storage system for collaborative applications Ad-hoc network of portable computers participate in managing a mobile, replicated storage system Suitable for a group of collaborators, all mobile and disconnected from fixed network, sharing (reading/writing) appointment calendars, meeting notes, evolving design documents, etc.

45. 45 Novel Aspects of Bayou

46. 46 The Bayou Architecture

47. 47 Application-Specific Conflict Resolution in Bayou Along with desired update, a write operation includes a dependency check: server query & expected query results As a pre-condition to performing the write operation, the dependency check must succeed A conflict is detected if query, when run against server data, does not produce same results.

48. 48 Application-Specific Conflict Resolution in Bayou If dependency check fails, write is not performed and server runs a merge procedure: also submitted along with the write operation templates or rules written in a high-level interpretive language uses server data and application-specific data to resolve the conflict when run, produces a revised update request Write operations are atomic

49. 49 Conflict Resolution in Bayou Example (Application-specific): Write { reserve an hour time slot by meeting room sched application; dependency_check: (list of previously scheduled meetings that overlap with requested time slot, NULL); merge_procedure: (); } Others: detect read/write conflicts detect write/write conflicts

50. 50 Replication Management in Bayou Clients send their writes to only one server (weak consistency) Bayou servers propagate their writes during pair-wise contacts. This process is called Anti-entropy and results on the two server agreeing on the writes and their order. Eventually all writes will reach all servers (eventual consistency)

51. 51 Bayou: Summary

52. 52 Case Study 2: Odyssey Odyssey client architecture Odyssey system components Odyssey applications: Video player Web browser

53. 53 Odyssey Client Architecture

54. 54 Main Features of Odyssey Application-aware adaptation approach Odyssey monitors system resources and notifies applications of relevant changes Applications decide when and how to adapt, to maintain certain level of fidelity General support for adaptation: Viceroy Type-specific support: Warden Caching support

55. 55 Odyssey System Components Odyssey Objects Client API to allow applications to: operate on Odyssey objects express resource needs (expectations) be notified when needed resources are no longer available respond by changing levels of fidelity

56. 56 Odyssey API

57. 57 Video Player in Odyssey

58. 58

59. 59 Odyssey: Summary

60. 60 Case Study 3: Rover Basic features of Rover Novel features of Rover Rover system components Constructing mobile applications using Rover Rover applications

61. 61 Basic Features of Rover Rover is a ToolKit for developing applications that can be used in both the fixed and mobile environment Supports both application-transparent and application-aware adaptations Supports the dynamic client/server model Can build Rover apps from scratch or migrate existing apps (with some effort) to be mobile

62. 62 Novel Features of Rover Support for: Mobile objects disconnected operation dynamic client/server Mixed communication/computation modes: Relocatable Dynamic Objects (RDO) Queued Remote Procedure Calls (QRPC) Applications decide to use RDO or QRPC

63. 63 Relocatable Dynamic Objects (RDO) Objects can be relocated from the fixed network to the mobile computer. Client applications then interacts directly with the local copy of the RDA If cached RDO is updated it can be tentatively considered the primary copy and is exported back to the fixed network Advantages: Performance (under weak connectivity) and functionality (under disconnections)

64. 64 Queued RPC (QRPC) Non-blocking remote procedure calls, even when fixed host is disconnected Client applications use QRPC to fetch RDO’s. Upon connection, or when an RDO arrives, the requesting client is called back QRPC is also used to commit updates made to RDO’s Non-executed QRPC’s are kept in an operation log As network connection comes and goes, the operation logs are flushed back to the servers

65. 65 Rover’s Relocatable Dynamic Object (RDO) Architecture

66. 66 Rover Component Architecture

67. 67 Constructing Mobile Applications in Rover Split the application into clients and servers modules Decide where each module resides initially (mobile host or fixed network) Encapsulate each module as an RDO Add application-specific semantics to RDOs Add application-specific conflict resolution procedures.

68. 68 Rover Applications Application-transparent adaptation Rover NNTP proxy and Rover HTTP proxy Application-aware adaptation Rover Exmh (mail browser), Rover Webcal (distributed calendar system), Rover Irolo (graphical Rolodex tool), and Rover stock market watcher

69. 69 Rover: Summary

70. 70 Mobile Objects/Agents (Cougaar, Aglets) Pieces of code that can freely roam the network Mobile objects allow clients to download the server code to mobile host for execution They can maintain state information and make intelligent decisions Challenge in using mobile objects? Frequently disconnected or weak environment

71. 71 Mobile Data Access Some slides and Diagram courtesy Mike Franklin, UMD (Lead the Broadcast Disks project)

72. 72 Mobile Data Access Mobile data access enables the delivery of server data and the maintenance of client-server data Data Access strategies in mobile environment can be characterized by Data delivery Data organization Consistency requirement Data Delivery Modes Client –pull Server-push Hybrid delivery In fact, this is instance of the more general problem of scalable content delivery

73. 73 Dissemination based Application Applications where content is delivered to a large number of clients Stock tickers Sport tickers Real-time video broadcasts Software updates (Got redhat 9 yet?) Entertainment/News delivery Others? How well does it scale? Use the web to deliver Heavy traffic, central point of failure

74. 74 What is the problem? Asymmetric applications, but web is symmetric Asymmetry: client to server ration Mouse and keyboard clicks vs. content and update Asymmetry ? Couch Potatoes Most people are informational couch potatoes …thankfully

75. 75 Push is the answer? Traditional pull (e.g., RPC) requires two way interaction “push” can solve some types of asymmetry Update – no need for polling Client-Server ratio: clients don’t need to bother Network: reduce or eliminate back channel use

76. 76 Push and Pull Overloaded terms Push vs. pull is just one dimension to compare data delivery mechanisms Different mechanisms for data delivery can and should be applied at different points in the system

77. 77 Server Data Dissemination With mobile nodes, asymmetric communication and resources emphasized Which alternatives does it make sense to use? Scalability problems for applications with asymmetrical communication Solution: Broadcast –based dissemination Broadcast disk Indexing on air Increases query time Decreases Listening time

78. 78 Mobile Data Management in C/S Design Push/Pull data dissemination Broadcast disks Indexing on air Client caching strategies and cache invalidation algorithms

79. 79 Push/Pull Data Dissemination Pull data delivery: clients request (validate) data by sending uplink msgs to server Push data delivery: servers push data (and validation reports) through a broadcast channel,to a community of clients

80. 80 Broadcast Disks

81. 81 Indexing on Air Server dynamically adjusts bcast hotspot Clients read the index, enters into doze mode, and then perform selective tuning Query Time: time taken from point a client issues a query until answer is received Listening Time: time spent by client listening to the channel.

82. 82 Caching in Mobile Client/Server: Problems Cashing is critical to many applications such as Web browsing and file and database systems Classical cache invalidation techniques do not work effectively in the mobile environment because of: client disconnection (call-backs do not work) slow and limited up-link bandwidth for client invalidation (detection approach is inefficient) very limited scalability for application servers with a large number of clients limited caching capacity due to client memory and power consumption limitations

83. 83 Caching in Mobile Client/Server: Solutions Variable granularity of cache coherency (Coda) Enabling ideas: Broadcast disks: periodic broadcast of disk-organized data; does not require upstream communication for disk reads Indexing on the air: broadcast of disk and its index; allows selective tuning; increases access time but reduces tuning time; allows dormant state Cache cache invalidation: Broadcasting Timestamps [Barbará et al] Bit Sequence [Jing et al]

84. References J. Jing, A. Helal, A. Elmagarmid, "Client-Server Computing in Mobile Environments," ACM Computing Surveys, June 1999. B. Noble, M.Satyanarayanan, D. Narayanan, J. Tilton, J. Flinn, K. Walker "Agile Application-Aware Adaptation for Mobility," Proceedings of the Sixteenth ACM Symposium on Operating Systems. M. Ebling and M. Satyanarayanan, "On the Importance of Translucence for Mobile Computing," Proceedings of the 15th ACM Symposium on Operating Systems Principles, May 1998, , CO A. Joseph and M. Kaashoek, "Building Reliable Mobile-Aware Applications using the Rover Toolkit," To appear in ACM Wireless Networks (WINET). R. Gray, D. Kotz, S. Nog, D. Rus, and G. Cybenko, "Mobile Agents for Mobile computing," Technical Report PCS-TR96-285, Dept. of Computer Science, Dartmouth College, May 1996. B. Zenel and D. Duchamp, "A General Purpose Proxy Filtering Mechanism Applied to the Mobile Environment," Proceedings of the third annual ACM/IEEE Conference on Mobile Computing and Networking, Sept. 1997.

85. References S. Zdonik, M. Franklin, S. Acharya, and R. Alonso, "Are ``Disks in the Air'' Just Pie in the Sky?," Proceedings of the IEEE Workshop on Mobile Computing Systems Applications, Santa Cruz, CA, December 1994 Application and Network Support for InfoPad, Narayanaswamy et al WebExpress: a system for optimizing Web browsing in a wireless environment, Housel and Lindquist, Mobicom 1996 S. Acharya, R. Alonso, M. Franklin and S. Zdonik,"Broadcast Disks: Data Management for Asymmetric Communication Environments," Proceedings of the ACM SIGMOD, Conference, San Jose, CA, May 1995. S. Hameed and N. Vaidya, "Log-time Algorithms for Scheduling Single and Multiple Channel Data Broadcast," Proceedings of the third annual ACM/IEEE Conference on Mobile Computing and Networking, Sept. 1997. H. Lei and D. Duchamp, "An analytical approach to file prefetching," USENIXAnnual Technical Conference, 1997.

  • Login