1 / 24

Replication for Mobile Computing

Replication for Mobile Computing. Prasun Dewan. Department of Computer Science University of North Carolina dewan@unc.edu. Mobile Data. Address Book Documents Spreadsheets Drawings Maps Programs. Logical link. Physical Location?. Physical Location. Local Client. Network.

ania
Télécharger la présentation

Replication for Mobile Computing

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Replication for Mobile Computing Prasun Dewan Department of Computer Science University of North Carolina dewan@unc.edu

  2. Mobile Data • Address Book • Documents • Spreadsheets • Drawings • Maps • Programs Logical link Physical Location?

  3. Physical Location Local Client Network Remote Server

  4. Client vs. Remote • Local Client • No network cost • latency • $$$ • Availability • Disconnection is default • Involuntary • out of range • power outage • Voluntary • preserve battery • saving money • Remote Server • Larger Data Size • More Secure & Robust • Sharing possible

  5. “cache” Coda Solution: Hybrid Scheme Local Client Network • While connected, remote server Remote Server • While disconnected local client

  6. Classic caching Uncached data always available but with higher cost Caching for future performance Filled on demand Stale data purged Writes to cache committed immediately Hoarding Uncached data unavailable when disconnected Caching for future performance & availability partial replication Filled on demand/pre-fetched Stale data sometimes better than no data Writes to cache committed later on reconnection tracking changes conflict detection conflict resolution Caching vs. Hoarding

  7. Cache data • Write through (immediate commit) Hoarding Logical Reconnection Emulation Disconnection Merging Physical Reconnection • Detect conflicts • Resolve conflicts • Provide access to cached, possibly stale data • Track changes to cached data (delayed commit) State Transition Diagram

  8. Classic cache filling/replacement granularity = disk block/cache line priority = f ( recent usage) filled on access Coda cache filling/replacement granularity whole file remote disk address meaningless system-determined prefetching ancestor directories path name resolution priority = f (recent usage, user-specified) user-determined prefetching filled on access, user-request, and periodically Cache replacement/filling

  9. Expanded during name-binding phase User-Determined Prefetching Per user, per workstation hoard profiles, specifying • Files to be added or deleted • Current and future (+) • children (c) • or descendents(d) • Priority Personal Files a /coda/usr/jjk d+ a /coda/usr/jjk/papers 100:d+ Source Files a /coda/src/venus 100:c+ a /coda/include 100:c+ Executables a /usr/X11/bin/xterm a /usr/X11/bin/xinit

  10. Two-phase Hoard Walk • Phase 1: Reevaluate name bindings • new children matching user-specifications may have been created by other clients. • Phase 2: Recalculate priorities, evict and fetch if necessary • no un cached object higher priority than cached objects

  11. Emulation • Log changes to files • mkdir d1,write f1, …. • Compress logs • (mkdir d, rmdir d, write f, write f) <=> write f • Level of write logging? • write f, contents • No need to store open and close • File updates not interleaved • write f, atOffset, buffer • More efficient • Compression advantages • some traces only 20% • others 40-100 % • variability because of hot files?

  12. Merging • Problem because of concurrent conflicting modifications • Cached and server data may be modified simultaneously. • Find and resolve conflicts • Concurrent directory changes resolved automatically • Not so for files

  13. Directory Merging (from LOCUS) • Operations • add(d, e) • del(d, e) • mod(d, attr, val ) • Link • Conficts • Client: add(d, e), uncached e existed on server at hoard time or server did added e to d subsequently • Client: mod(a1, v1), Server: mod(a2, v2) • Client: changed d; Server: deleted d • Or vice versa

  14. write (d1/e1) link (d1/e1, d2/e2) del(d1, e1) conflict False Conflict Example touch d1/e1 mv d1/e1 d2/e2

  15. File Merging • Harder problem because file is unstructured from OS point of view • Let application program that understands file structure and semantics detect and resolve conflicts • Drawing program allows concurrent additions like directory • Calendar program allows reservations at different times. • Or let user resolve conflicts • User makes different reservation • System simply calls application program

  16. Issues raised by Coda • Considers strong connection and disconnection • weak connection? hoarding, emulation, or something else? • Client to server merging • client to client? • User-determined pre-fetching of files • System-determined • Application determined? • Merging depends on physical rather than logical connection. • Sometimes user wants separate version to keep changes private. • User-defined transactions!

  17. Issues raised by Coda • Automatic directory merging • Synchronization guarantees a la serializability? • Inflexible resolution • May want both server and client to delete for delete to succeed (user cleaning up local hoard) • Manual (Application or end-user) file merging • Automatic (with guarantees)? • Directory and file hoarding and merging • Smaller grain than file. • Non persistent data • What if changes rejected. • Cascaded rollbacks

  18. Issues raised by Coda • Client to server merging • client to client? Anti-Entropy Epidemic Algorithms • News, Lotus Notes, Bayou, TACT • Clients do pair-wise merging • Eventually consistency • Problem of write order since no single arbitrator • In host priority order

  19. One- vs Two-level P2P Architectures Lotus Notes client client merging News, Grapevine, Bayou server server client

  20. One- vs Two- Level C2S Architectures Sync server client Coda server server merging client

  21. Issues raised by Coda • What if changes rejected. • Cascaded rollbacks • Bayou • Uncommitted writes are tentative • System keeps track of tentatively written objects. • Application can display this to user

  22. Issues raised by Coda • Merging depends on physical rather than logical connection. • Sometimes user wants separate version to keep changes private. Rover • Application explicitly imports (caches) and exports (merges) objects. • Merge-aware application.

  23. Issues raised by Coda User-determined pre-fetching of files • System-defined • Application-defined

  24. Issues raised by Coda User-determined pre-fetching of files • System-defined • Application-defined User-determined pre-fetching of files • System-determined • Detection of file working sets. • Look at past behavior. • Trace data. • What executables forked. • What files accessed. • If current behavior looks like past behavior, cache data. • Metric for similarity. • Look at semantic distance between files.

More Related