Odyssey Support for Mobile, Adaptive Applications - PowerPoint PPT Presentation

1 / 45
About This Presentation
Title:

Odyssey Support for Mobile, Adaptive Applications

Description:

Round-trip time. Throughput ... Stock tickers. Sport tickers. Real-time video broadcasts. Software updates (Got redhat 9 yet? ... – PowerPoint PPT presentation

Number of Views:68
Avg rating:3.0/5.0
Slides: 46
Provided by: csBing
Category:

less

Transcript and Presenter's Notes

Title: Odyssey Support for Mobile, Adaptive Applications


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

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
  • Lets 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 mobility
  • Odyssey to the rescue...

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
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
Client Adaptation
  • Make mobile clients more robust by offering
    adaptation
  • rely on servers when possible
  • function autonomously if needed
  • monitor and adjust to current conditions
  • Change application expectations

7
Adaptive Applications
  • applications consume resources
  • network bandwidth, CPU cycles, battery power,
    disk space,
  • resources are variable
  • so
  • applications adapt use of resources as resource
    quality changes

8
Who Controls Adaptation
  • The Operating System?
  • Individual applications?
  • Both!
  • Application-Aware Adaptation

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
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
(No Transcript)
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
Odyssey
  • A Platform for adaptive mobile data access
  • Built a prototype for Unx as OS extension
  • Provides a small API to the application
  • Implementation
  • Need a central component for resource monitoring
    and management (Viceroy)
  • Need data aware components that offer fidelity
    choices (Wardens)

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
Odyssey Architecture
Application
Web Warden
viceroy
Odyssey runtime
Video warden
Upcalls
Odyssey calls
Sys calls
Tsop, request
Interceptor
kernel
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?

Fid. 1
Fid. 2
Fid. 3
Fid. 4
Available bandwidth
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
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 unx ioctl()
  • Can also be used to request type specific
    operations

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

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, Nobles group followed up with agility
    estimation work for ad hoc networks

21
Agility (cont.)
22
Agility (cont.)
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
Client Server Based Solutions
  • Server, typically
  • Stationary host
  • Possibly replicated
  • Resource rich
  • Holds long running state
  • Client, typically
  • Mobile host, intermittent connectivity
  • Resource poor, etc..
  • Communication restricted between client and
    server, no mobile-to-mobile communication

25
Extended Client-Server Model
  • Classic client-server systems assume that the
    location of client and server hosts do not change
    and also the connection among them does not
    change
  • Functionality between client and server is
    statically partitioned
  • Extended Client server Architecture thus deals
    with these inconsistencies in network connections
    and location specifics

26
Extended Client-Server Model
  • Thin client architecture
  • Full client architecture
  • Flexible client architecture

27
Thin client architecture
28
Full-Client Architecture
  • Can support disconnected or weakly connected
    client
  • The full client architecture supports emulations
    of functions of server at client host
  • Light weight servers or proxy
  • E.G CODA , WebExpress

29
Flexible Client-Server Architecture
  • Generalizes both thin client and full client
    architecture
  • Connection between client and server can be
    dynamically established

30
Client-Server Application Adaptation
  • The Rover toolkit supports application aware
    adaptation through the use of RDO
    http//www.pdos.lcs.mit.edu/rover/
  • RDOs are relocatable dynamic objects (more in a
    second)
  • Philosophy/Motivation similar to Odyssey
    approach is different
  • Odyssey changes application in place
  • Rover allows responsibility to be exchanged
    between client and server
  • Benefits to Application Designers
  • Application designers have semantic knowledge
  • Can tightly couple data with program code and
    manage resources

31
Key Ideas
  • Relocatable Dynamic Objects
  • Objects (code and data) that can be exchanged
    between the client and the server why?
  • Queued Remote Procedure Calls (QRPCs)
  • Asynchronous/non-blocking RPC calls
  • If disconnected, application can continue
    execution
  • RPC executed upon reconnection

32
Programmers tasks
  • Define RDOs
  • for data types manipulated by the application
  • For data exchanged between client and server
  • Partition application
  • Portions that run on client and those that run on
    server
  • They communicate using QRPC
  • Define methods for updating objects
  • Includes conflict detection and resolution

33
Using Rover
  • Programmer links code with toolkit
  • Application cooperates with runtime environment
  • Imports RDOs
  • Invokes methods on RDOs
  • Export logs of invocation to servers
  • Reconcile copies of objects with those at server
  • Similar to agents?
  • Similar to process migration?

34
(No Transcript)
35
Proxy-Based Application Adaptation
  • The application specific proxy has been proposed
    as an intermediary between client and server
  • It performs storage intensive and computation
    intensive tasks
  • Proxy reduces Bandwidth demands and allow legacy
    and non standard client to communicate with the
    server

36
Mobile Objects/Agents
  • 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

37
Collaborative Groups
  • Division of members into groups
  • Members can access data for the group
  • A client is able to access data residing on
    server to which it is communicating or any
    machine holding the copy of the database,
    including personal laptop, should be willing to
    server read and write requests from nearby
    machines
  • E.g., Bayou system

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

39
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

40
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

41
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

42
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 dont need to bother
  • Network reduce or eliminate back channel use

43
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

44
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

45
(No Transcript)
Write a Comment
User Comments (0)
About PowerShow.com