Department of Computer Science

Transcription

1 Department of Computer Science Institute for System Architecture, Chair for Computer Networks Application Development for Mobile and Ubiquitous Computing 8. Disconnected Operations Dr. Ing. Thomas Springer Technische Universität Dresden Chair of Computer Networks

2 Structure Disconnected Operations CODA filesystem Mobile Database Systems Rover system Generalization of concepts Ocassionally-Connected Operations Concepts Weakly-connection support in CODA Autonomous Operations 2

3 Motivation Challenge: disconnections due to mobility foreseeable (due to energy saving, communication costs, location changes) unforeseeable (uncovered regions, unavailability of servers, network congestions) Goal: Availability of application functionality and data also during phases of disconnection preparation of disconnections during connection phase Transparency for programmer and user: o Application perspective: hiding disconnections from applications o User perspective: application usage without interuptions 3

4 Coda Distributed File System Distributes file system with disconnection support goal - high availability and scalability supports a global namespace replication and caching of whole files at client side emulation of file server functionality during disconnections prefetching of files (hoarding) to improve file availability optimistic consistency mechanisms automated conflict detection and resolution application dependent conflict resolution Noble, Satyanarayanan (Carnegie Mellon University) 4

5 Coda - Architecture distributed and replicated file server on server side proxy on client side (cache manager, server emulation) 5

6 Disconnection Handling in Coda Cache Manager Noble, Satyanarayanan (Carnegie Mellon University) hoarding database, prefetching Hoarding disconnection logical reconnection Emulation disconnection physical reconnection Reintegration server emulation files from cache logging of updates reply of logs automated conflict resolution application specific conflict resolver 6

7 Coda Phases Preparation phase Hoarding direct access to remote file servers client-side caching of whole files prioritized caching algorithm o balance between - short-term need of caching for performance and - long-term need of caching for availability (hoarding) o Least recently used scheme (LRU) for cache management o combined with per device prioritized file list (hoard database) user defined file list for prefetching o hoard profile: script for specifying a set of files to be cached o indication of their importance based on hoard priority o tool support for creating hoard profiles periodic cache updates hoard walking o first phase update file sets (e.g. for full path hoarding) o second phase re-evaluation of all priorities in cache and hoarding db, cache update 7

8 Coda Sample Hoard Files 8

9 Coda Phases Disconnection phase - Emulation optimistic locking strategy local file changes immediately visible error message for access to uncached files modification record (change modify log, cml) o log entry contains copy of the performed file operation and the version state of all involved files o operations are reexecuted on server during reintegration (replay log) optimization of modification log o reduce required storage for change modify log o increases reintegration performance o any operation which overwrites the effect of previous operation cancel corresponding record logs (e.g. delete cancels create and write operations) versioning of files for conflict detection 9

10 Coda Phases Reintegration phase Reintegration logged actions send to server and replayed conflict detection and automatic conflict resolution based on version comparision o same name for a newly created directory o parallel change of directory attributes as client and server o file changed in parallel at client and server application specific conflict resolution o application specific conflict resolvers provided by application developer (includes knowledge about file content) o tool for manual conflict resolution 10

11 DISCONNECTED OPERATIONS IN MOBILE DATABASE SOLUTIONS

12 Classes of Mobile Database Systems Embedded Mobile Databases Local lightweight database embedded into application Examples: PointBase, SQLite, ianywhere s UltraLite, etc. Mobile Client/Server Databases Lightweight database synchronized with database server Examples: DB2 Everyplace, Oracle 10g lite, Tamino Mobile Suite etc. 12

13 Integrated Mobile Databases Pointbase Micro: Java-based relational database optimized to run on the Java Micro Edition (CDC and CLDC/MIDP) and Java SE platforms. ultra-compact footprint (<45K for J2ME MIDP) embedded within a Java applications Access via JDBC Subset of SQL92 Transaction support 13

14 Integrated Mobile Databases SQLite Embedded SQL database engine Serverless, reads and writes directly to ordinary disk files Features Support of local ACID transactions including nested transactions Implements most of SQL92 Self-contained (no external dependencies) Cross-platform support (db files can be moved) Small code footprint: < 300KB fully configured or less than 180KB with optional features omitted. SQL Command Processor Interface Virtual Machine Database Management DB File (one DB file per Filedatabase) (one DB file per Filedatabase) (one file per database) Tokenizer Parser Code Generator 14

15 Integrated Mobile Databases Local data access Runs on local device, embedded into application No dependency on established, permanent network connection Small footprint Good performance DB in the scope of one application -> no sharing of data between applications 15

16 Mobile Client/Server Databases - Overview A mobile database system consists of a set of components components are distributed over mobile and stationary device Two architectures Extended Client/Server system Middleware system with replication server 16

17 Extended Client/Server system Synchronization Client replica selection Synchronization Server Lightweight DBMS Synchronization Server-DBMS mobile Database (replica) Mobile Client Master database Database System Client runs lightweight replica containing a subset of the master DB Lightweight DB performs operations locally in disconnected mode (server emulation) Resynchronisation not permanently but triggered by client or periodically performed by system Figure according to Mobile Datenbanken und Informationssysteme Hagen Höpfner, Can Türker, Birgitta König-Ries 17

18 Middleware system with replication server Synchronization Client Synchronization Server Lightweight DBMS Server-DBMS mobile Database (replica) Master database Mobile Client Database System Synchronization Client Lightweight DBMS Replication Server Synchronization Server Server-DBMS mobile Database (replica) Mobile Client Master database Database System Intermediary middleware server for replication providing decoupling of Mobile DB and Master DB multiple sources can be integrated at the replication server (transparent for client and server) replication server can disburden data sources access control at replication server Figure according to Mobile Datenbanken und Informationssysteme Hagen Höpfner, Can Türker, Birgitta König-Ries 18

19 Replica selection Explicit replica selection Client or administrator define data to be replicated at connection phase Main difference to caching (implicit selection of cached data) Replica definition typically in two steps 1. Design time of DBS: Definition of data for potential replication (publication) 2. Runtime of application: Selection of published data for replication (subscription) 19

20 Example: DB2 Everyplace Architecture: Middleware system with replication server Figure according to Mobile Datenbanken und Informationssysteme Hagen Höpfner, Can Türker, Birgitta König-Ries 20

21 Example: IBM DB2 Everyplace DB2 Everyplace: lightweigth DB system for mobile and embedded devices supports subset of SQL language o creation and manipulation of tables o not supported: stored procedures, user defined functions, trigger, views, subqueries GUI for creation of DB queries Query-by-Example (QBE) Sync Client triggers synchronisation Communication with Sync Server Synchronization based on database tables Sync Server User authentification manages synchronisation between DB2 Everyplace and Master DB propages all changes in DB2 Everyplace to Master DB and updates in Master DB to DB2 Everyplace 21

22 Replication Tools Mobile Device Administration Center (MDAC) XML Scripting tool Allow definition of part of Master DB to be replicated at granularity of tables specification of horizontal or vertical filters to select particular rows or columns target table can be created out of data from multiple tables (join, merge) target tables can be read-only or read-write for read-write restrictions o no aggregations for row/column selection o source table must not be created based on join or merge of other tables o just tables replicated (no integrity definition nor trigger) 22

23 Architecture of the DB2 Everyplace engine Application 1 Application n CLI/ODBC/JDBC SQL Runtime Environment Parser Semantics Optimizer Interpreter Catalog Management Data Manager Services DMS Record Manager Index Manager Cryptoplugin Crypto Library (Optional) Catalog Tables Catalog Indexes Temporary Tables Shadow files Buffer & Recovery Mangement File System Interface User Tables User indexes Ref: DB2 Everyplace Database Release 8.1: Architecture and Key Features, Thomas Fanghänel, Jonas S Karlsson, Cliff Leung 23

24 Queries and Transactions DB2 Everyplace supports subset of SQL supports join, merge, sort creation and removal of tables and indexes on mobile client tables can contain primary keys, foraign keys and checkclauses QBE supported on Palm devices o for data view and manipulation only (no table creation) Changes of read-write tables performed within transactions o local changes are tentative until synchronization is sucessfully performed with master DB 24

25 Synchronization Initiated manually by user automatically by Sync Client Steps for synchronizing local changes with master DB 1. After initiation Sync Client sends request to Sync Server 2. Sync Server authenticates request (request contains login and password of user), if sucessful request is enqueued, client receives ack 3. Changes are sent to Sync Server and stored in Staging table, enables continuous work at client 4. Changes in Staging table performed on mirror database, conflict detection and resolution 5. Changes in mirror table are logged in change table, log is used to propagate changes on master DB 25

26 Steps for synchronizing local changes with master DB DB2 Log Capture Change Mirror Data Tables table Apply DB2 Everyplace DB2 Everyplace table table DB2 Everyplace DB input queue Logging write updates Mirror Mirror table table copy updates, resolve conflicts Staging Staging table table Mirror DB sync request Mobile Client Admin Control DB Middleware Master DB Database Server 26

27 Conflict handling Detection based on version numbers For each table row version number maintained by Sync Server and Sync Client Differing version numbers mark conflicts Conflict Handling Default: o changes rejected, o transaction rolled back o logging of conflict o mobile DB updated with data from mirror DB User-based conflict resolution o based on program for log search o application-specific conflict resolution implementable 27

28 ROVER - A DISTRIBUTED OBJECT-ORIENTED SYSTEM

29 Rover Replication of Objects distributed object-oriented system support for disconnection handling and low bandwidth connections dynamic placement of objects queued remote method calls 29

30 Rover - Architecture Client-side application application import/invoke/export application Server-side application RPC Log Access Manager Object Cache bind/fetch/flush Access Manager RPC Log system Network Scheduler DCE HTTP TCP SMTP HTTP/SMTP/TCP TCP SMTP DCE HTTP Network Scheduler network 30

31 Rover Preparation and Disconnection Preparation replication of application objects (code and data) primary object on home server secondary objects (replicated objects) on client caching and prefetching of objects (what objects? application, when? network scheduler) Disconnection local log of method calls within objects application dependent operations for log optimization (maintained and performed by access manager) local changes immediately visible (marked as tentative) 31

32 Rover Reintegration Reintegration of changes triggered by application export method called on object call log of object is transformed into remote calls written to local Operation Log maintained by Network Scheduler Network Scheduler controls connection and remote call transfer to home server 32

33 Rover Reintegration (Cont.) Conflict detection based on version vector for each object Conflict resolution per method conflict resolution performed at home server each method contains code for conflict resolution user has to handle conflicts if no automated resolution is possible changes are committed after successful execution on home server several levels of consistency for objects (uncacheable, immutable, verify-before use, verify-if-service-isaccessable, expires-after-date, service-callback) 33

34 GENERAL PRINCIPLES OF DISCONNECTED OPERATIONS

35 Disconnected Operations - Priciple monitoring of actions caching, prefetching Connected Service Functions Proxy-Client Disconnected Service Functions local server emulation Transition Function Connected Service Functions Proxy-Client Disconnected Service Functions change of data copies recording of actions Dispatcher Proxy-Server reintegration with server Dispatcher Proxy-Server introduction of proxy implementation of functionality for connections and disconnections (f.connected(), f.disconnected()) transition function for proxy state between connection/disconnection 35

36 Disconnected Operations 3 Phases preparation phase ensure local availability of data and code o replication of data and caching o monitoring of user actions and prefetching o static or dynamic installation of emulation code on client disconnection phase local server emulation o changes of local data copies o recording of actions reintegration phase mediate local changes to server o conflict detection and resolution 36

37 General Architecture client-side Proxy server-side Proxy Caching read data Prefetching Application transfer control Server write data Write Log Synchronization Synchronization

38 OCCASIONALLY CONNECTED OPERATIONS

39 Occasionally connected operations limits of disconnected operations limited task continuity due to lack of access to remote data local changes not visible to remote clients probability of conflicts raises with disconnection time local resources required for caching, logging of operations and server emulation bad performance and response times using low bandwidth links weak connection support mode of operation to hide network latencies minimized disconnection times lower resource requirements on mobile devices increased consistency and task continuity decreased probability of conflicts low bandwidth links require explicit support 39

40 Support of weak connections Mechanism for adaptive and dynamic use of connection resources load of new data and cache updates reintegration of local changes Load of requested data has highest priority to support task continuity and short response time Cache updates and reintegration independent from response times fast reintegration decreases size of local operation log and conflict probability slower reintegration enables optimization of local operation log (e.g. eliminate operations), reduced amount of data for network transfer 40

41 Partially Connected Operations Extension of Andrew File System (AFS) All file system writes are performed locally and logged Three prioritized classes of data transmissions for efficient network usage 1. Interactive communication 2. Read/Fetch data 3. Write data for reintegration Classes have different priorities One send queue for each class Specific send strategy to prioritize interactive communication and high availability of data in cache 41

42 Coda - Weakly Connected Operations Extension of disconnected operations in Coda implicitly 2 classes of data transmissions 1. Read operations for missed and outdated files with high priority 2. Trickle reintegration in background with low priority only if no read operations active Calculation of tresh-hold for max. file size for reading new files error message for larger files 42

43 Coda - Weakly Connected Operations disconnection strong connection weak connection resolving strong distinction between connected and disconnected if small bandwidth network connection available operation in disconnected mode but performance of reintegration functionality 43

44 Coda Trickle Reintegration ongoing background reintegration with minimally impact on foreground activity balance between o effectiveness of log optimization and o conflict probability minimal dwell time (adjusted according current connectivity) o replay operation remains defined time in modify log (aging window) (10 min. based on simulations) reintegration optimization 44

45 AUTONOMOUS OPERATIONS

46 Autonomous Operations Generalization of disconnected operations local availability of data and code required can be performed on mobile device or infrastructure host o independent of established connection operation executed independently from user and network connection autonomous behavior (failure recovery, resource discovery) transmission of results to application or user if connection is re-established use of dynamic code installation or mobile code 46

47 Autonomous Operations migration: transfer of code, data, state collect intermediate results local interactions with server objects and other resources transfer of the result after reconnection 47

48 Summary Goal: work with mobile devices similar to stationary PCs Combination of Mechanisms Emulation of server on client-device Caching/Prefetching Replication Logging Adapted network usage Mechanism are general, no application specific behaviour Autonomous Operations more general concept including disconnected operations 48

49 References IBM DB2 Product overview Mobile Datenbanksysteme Bela Mutschler, Günther Specht. Mobile Datenbanken und Informationssysteme Hagen Höpfner, Can Türker, Birgitta König-Ries Thomas Fanghänel, Jonas S. Karlsson, Cliff Leung: DB2 Everyplace Database Release 8.1: Architecture and Key Features The Ultra-Compact Database for Enterprise Mobility Product Datasheet. resourcecenter/pdfs/micro.pdf UltraLite Database Management and Reference Sybase ianywhere PointBase Micro : Product overview 49