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
       clients

     – 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
    medium



•   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
          data!



    Trade-Off:  Size means  Miss factor



    Trade-Off:  Size means  Miss factor
               Indexing

•   (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).
              Caching

•   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
       changes


•   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
             Prefetching

•   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
          Hoarding

     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
                 Coda

•   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
                                    connection
                       weak
 disconnection         connection

                                         write
                                     disconnected
                       connection


                                    disconnection

                 emulating




                                                    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


				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:8/8/2012
language:English
pages:34