IT 601

Document Sample
IT 601 Powered By Docstoc
					Fundamentals of mobile computing
Mobile Data Management
        Mobile data management

•   Issues
      – Battery power restrictions
      – Resource restrictions
      – Bandwidth restrictions and variability
      – Frequent/planned disconnections

•   Solutions
     – Power conservation techniques
     – Wireless broadcast, broadcast disks
           • Scheduling, indexing, caching
     – Disconnected operations
           • Prefetching, hoarding, caching, consistency
             Data broadcasting

•   Maximize query capacity of servers, minimize energy/query at client

     – asymmetric links (high b/w from server to client; low b/w from client to server)

•   Pull data delivery: clients demand, servers respond

•   Push data delivery: servers broadcast, clients listen
             Pull data delivery

•   Pull data delivery: clients demand, servers respond

     – clients request (validate) data by sending uplink messages to server

     – Advantages
        • Server has exact information about its clients’ needs
        • Adapts well to dynamic demand patterns

     – Disadvantages
         • Higher overhead – request channel required
         • Client needs to know server locations
               Push data delivery

•   Push data delivery: servers broadcast, clients listen

     – servers push data (and validation reports) through a broadcast channel,to a community of

     – data are selected based on profiles and registration in each cell

     – Advantages :
        • Server location transparency
        • client energy is saved by needing receive mode only
        • scales to any number of clients

     – Disadvantages :
         • Server does not have exact information
         • Does not adapt well to dynamic demand patterns
Push and Pull data delivery

•   Push and Pull data dissemination: Sharing the channel

     – Selective Broadcast: Servers broadcast "hot" information only

     – On-demand Broadcast: Servers choose the next item based on requests
    Organization of broadcast data

•   Flat: cyclically broadcast the union of the requested data

                                      A B C

•   Skewed (Random):
     – broadcast different items with different frequencies
     – goal is that the inter-arrival time between two instances of the same item matches the
        clients' needs

                                     A A B C
        Broadcast Disks

Disk1   A
Disk2   B   C

   A B A C
             Broadcast Disks
•   Periodic broadcast of one or more disks using a broadcast channel

•   Multiple disks of different sizes and speeds are superimposed on the broadcast

•   Data broadcast with the same frequency are viewed as belonging to the same disk

•   Frequency of broadcasting each item depends on its access probability

•   Disk speed can be changed based on client access pattern
             Scheduling algorithms

•   First Come First Served (FCFS)

•   Most Requests First (MRF)

•   Longest Wait First (LWF)

•   Requests times Wait (RxW)
     – Broadcast a page either because it is very popular or because it has at least one long-
       outstanding request
            RxW: Assumptions

•   Fixed (equal) size data items
     – Time required to transmit one item is called a “broadcast tick”
     – Time is measured in broadcast ticks

•   Clients keep listening after making a request

•   No transmission errors

•   Delay for sending requests ignored
        RxW: Basic Algorithm

•   For each page with outstanding requests, maintain

     – PID – Page Identifier

     – REQcnt – Number of outstanding requests

     – 1stARV – Timestamp of earliest unsatisfied request
            RxW: Algorithm

•   On request arrival
     – Lookup the page
     – If found,
          • Increment REQcnt
     – Else
          • Add new entry; REQcnt = 1; 1stARV = Current time

•   At each broadcast tick
     – Broadcast the page with maximum value of (RxW) where
          • R = REQcnt
          • W = clock – 1stARV, where clock is the current time
             RxW: Pruning Algorithm

•   The basic algorithm is O(n)

•   Work can be reduced by recognizing that not all pages need be considered

•   Maintain two lists :
     – Requests – Sorted by REQcnt descending
     – Wait – Sorted by 1stARV ascending
             RxW: Pruning

•   On request arrival

     – Put (or move) the page’s entry to its proper place in Requests

     – Optimization – Maintain a “REQcnt index”
        • Has pointers to “clusters” of equal REQcnt
        • On a request, a page can move up only one cluster
              RxW: Pruning

•   At broadcast tick
     – Start from the top of Requests (Entry : REQcnt’, 1stARV’)
     – Prune the Wait queue :
           • 1stARV  Clock – (MAX / REQcnt’)

     – Start from the top of Wait queue
     – Prune the Request queue :
         • REQcnt  MAX / (Clock – 1stARV’)

•   Repeat this until the search reaches the bottom of one of the lists
             Indexing on Air

•   Server dynamically adjusts broadcast 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

•   Aim : Minimize client's access time and tuning time
     – active mode power is 250mW, in doze mode 50μW

                                                                                      Source: Helal
             Access Protocols

•    Two important factors affect access time:
    1.    Size of the broadcast
    2.    Directory miss factor - you tune in before your data but after your directory to the

    Trade-Off:  Size means  Miss factor

    Trade-Off:  Size means  Miss factor

•   (1,M) Indexing:
     – We broadcast the index M times during one version of the data.
     – All buckets have the offset to the beginning of the next index segment.

•   Distributed Indexing:
     – Cuts down on the replication of index material
     – Divides the index into:
                 Client Caching

•   Data are cached at clients to improve access time

•   Lessen dependency on the server's choice of broadcast priority

•   Traditionally, clients cache "hottest" data to improve hit ratio

•   Cache data based on PIX:
     – Probability of access (P)/Broadcast frequency (X).

•   Cache data replacement
     – cost-based is not practical
     – requires perfect knowledge of access probabilities
     – comparison of PIX values with all resident pages

•   Alternative: LIX, LRU with broadcast frequency
     – pages are placed on lists based on their frequency (X)
     – lists are ordered based on L, the running avg. of interaccess times
     – page with lowest LIX = L/X is replaced
    Client cache invalidation

•   Why?
     – Value of data may have changed since caching by client

•   When?
     – Synchronous: send invalidation reports periodically
     – Asynchronous: send invalidation information for an item, as soon as its value

•   To whom?
     – Stateful server: to affected clients
     – Stateless server: broadcast to everyone

•   What to send?
     Disconnected Operations

•   Goals
     – Efficient/transparent access to shared files within a mobile environment
     – Support for disconnected operations while maintaining data consistency

•   Approaches
     – Replication of data (copying, cloning, caching)
     – Getting data in advance (hoarding, fetching)

•   Main problem: consistency
          • Assumption: simultaneous sharing other than read is rare
     Caching for disconnection

•   What to cache?
     – Entire files, directories, tables, objects
     – Portions of files, directories, tables, objects

•   When to cache? Is simple LRU sufficient?
     – LRU captures an aspect of temporal locality
     – Predictive/semantic caching: based on the semantics distance between data/request
         Cache consistency

•   Typical mechanisms: strong consistency (via atomic updates)
     – Invalidation of caches through a server
     – Cannot be used in mobile environments
     – Mobile computer may not be connected to network

•   One solution: weak consistency
     – Tolerate occasional inconsistencies
     – Apply conflict resolution strategies subsequently

•   Online strategy to improve performance
     – prepaging
     – prefetching of file
     – prefetching of database objects

•   What to fetch?
     – access tree (semantic structure)
     – probabilistic modeling of user behavior

•   Old idea that can be used during network idle times

•   Combine delayed writeback and prefetch

     a technique to reduce the cost of cache misses during disconnection
     That is, load before disconnect and be ready.

•   How to do hoarding?
     – user-provided information (client-initiated disconnection)
          • explicitly specify which data
          • Implicitly based on the specified application
     – access structured-based (use past history)
          • E.g., tree-based in file systems
            Processing the Log

•   What information to keep in the log for effective reintegration and log optimization?
     – Data values, timestamps, operations

•   Goal: Keep the log size small to
     – Save memory
     – Reduce cost for update propagation and reintegration

•   When to optimize the log
     – Incrementally each time a new operation is performed
     – Before propagation or integration
Example file systems: Coda, Odyssey

•   Application transparent extensions of client and server

     – changes in the cache manager of a client

     – applications use cache replicates of files

     – extensive, transparent hoarding

     mobile client

         application                cache                     server

                                                                       Source: Schiller

•   Client-Server System with two classes of replication w.r.t. consistency

•   Disconnected vs. Weakly connected
    – Hoarding, Caching/Server callback, No Prefetching

•   During connections: Allows AFS clients (Venus) to hoard files.
    – hierarchical, prioritized cache management
    – track dependencies, bookmarks
Coda: States of a client

                 hoarding           strong
 disconnection         connection




                                                    Source: Schiller
          Coda: Emulation

•   During disconnections: Venus acts as (emulates) a server
    – generates (temp) fids, services request to hoarded files.

•   On reconnection, Venus integrates locally changed files to servers.
    – Considers only write-write conflicts - no notion of atomicity
    – User conflict resolution/ Application-aware adaptation [Odyssey]
    – Use optimistic replication technique
Any Question

Shared By: