mobile computing panos papadimitratos wireless networks lab department of electrical engineering...
Post on 20-Dec-2015
219 views
TRANSCRIPT
Mobile ComputingMobile Computing
Panos Papadimitratos
Wireless Networks Lab
Department of Electrical Engineering
Cornell University
Mobile Computing Mobile Computing EnvironmentEnvironment
Limited BandwidthHigh LatencyIntermittent ConnectivityLower ReliabilityLow Physical SecurityLower Processing CapabilityHigher Degree of Heterogeneity
Despite the adversity..Despite the adversity..
Run Distributed ApplicationsProvide Distributed ServicesShare DataRemain ConsistentRemain Efficient
Why are things more difficult?Why are things more difficult?
Connectivity is NOT continuous– Topological Changes
Less Resources
Consequently:– Lower Availability– Potential Inconsistencies
Two aspectsTwo aspects
“…Replicated, Highly Available, Weakly Consistent Storage System…”
“Develop Mobile Applications … minimize the dependence upon continuous connectivity…”
BayouBayou
Distributed Data Storage SystemDesigned for a Mobile Computing EnvironmentNon-TransparentWeakly-Consistent ReplicationApplication-Specific Mechanisms to Detect &
Resolve ConflictsLow Usage of the Network
Previous WorkPrevious Work Theory of Epidemics
– Eventual Consistency
Coda– Disconnected Operation– Optimistic Replication– Consistency
Application-specific resolvers Conflicts resolution based on file type Log unresolved conflicts, create error message
Ficus Notes, Oracle, MS Access
System ModelSystem Model
Client/Server Architecture -Transactional System
Data are replicated to a set of serversApplications run as clientsTwo Basic Operations: Read and WriteReplication is Weakly Consistent
– Read-Any-Write-Any Model
System ModelSystem Model
ApplicationBayou APIClient Stub
Server State
Storage System
Server State
Storage System
Read or Write
Anti-Entropy
Storage System
Server State
ApplicationBayou APIClient Stub
Conflict Detection & ResolutionConflict Detection & Resolution
Application-Specific– Notion of Conflict
Semantics Granularity – example: Scheduling Application
– Resolution Policy Semantics
Automated Mechanisms– Dependency Checks– Merge Procedures
Dependency ChecksDependency Checks
Application-Supplied Query & Expected ResultQuery is Run at the Server against its current dataIf Check Fails, invoke Merge procedure
Merge ProceduresMerge Procedures
High-level programs with application-specific knowledge
Run by the ServerPerformed Atomically as part of WritesAttempt to Resolve the ConflictProduce a Revised Update to Apply
Basic Anti-EntropyBasic Anti-Entropy
Goal: the reconciliation of replicas’ dataPair-wise mannerOne-way OperationPropagate Write OperationsAccept-Order ConstraintPrefix PropertyVersion Vectors
Basic Anti-EntropyBasic Anti-Entropy (continued)(continued)
S
R
R.V Version Vector
All Writes unknown to R
For each w in S.Write_logif (R.V(w.server_ID) < w.accept_stamp)
SendWrite(R,w)
A More Reasonable ApproachA More Reasonable Approach
Without an ever-growing Write Log– Need a method for Truncating the Write Log
Idea: An Update that is received by all Replicas need not be logged any more.
Allow for an independent, aggressive pruning by each Replica
The notion of Stable or Committed Write is pivotal in the pruning process
Write StabilityWrite StabilityStable Write: iff it has been executed for the last
time by a server. Intuitively equivalent to Confirmation or
Commitment Primary Commit Scheme
– Designate a Replica as Primary– Primary determines the order (position) of a Write
when it first receives it. – Stable Order
Any Non-Committed Write is called Tentative
Anti-Entropy Anti-Entropy (Revisited)(Revisited)
S
R
First, All Committed Writes unknown to R
if R.CSN < S.CSN for each w in S.Write_log if (w.accept_stamp < R.V(w.server_ID))
SendCommitNotification(…) else
SendWrite(…)
R.V Version Vector
R.CSN Highest Commit Sequence Number
Second, All Tentative Writes unknown to R
For each w in S.Write_logif (R.V(w.server_ID) < w.accept_stamp)
SendWrite(R,w)
Write-Log TruncationWrite-Log Truncation
Stable Order maintains the Prefix Property– Replicas can truncate any stable prefix from their
Write Logs
Incremental Reconciliation may not be possibleEach Replica needs to remember the omitted
Write OperationsFull-Database Transfer
‘‘Extended’ Anti-EntropyExtended’ Anti-EntropySession Guarantees
– Causal Order – Accept Stamp– Reduce Client-Observed inconsistencies
Eventual Consistency– Define a Total Order using the Server ID and
the Causal Order– Propagate Updates in this Total Order– Provide Guarantees on the ‘quality’ of the
Replicas Data Content
Other issuesOther issues
Light-Weight Server CreationSecurityUpdate through transportable storage
media, i.e. floppy disksLink quality determines the frequency of
the performed anti-entropies
ExperimentsExperiments
Measurements on a modified EXMH (e-mailer) that uses Bayou for storing messages – Only Committed Writes are propagated– Measure the execution time for an Anti-Entropy
(100 Writes) over different network links
Network TransferInserting Newly Received Writes
Bayou - SummaryBayou - Summary
Support for Arbitrary Communication TopologiesOperation over Low-Bandwidth NetworksIncremental ProgressEventual ConsistencyEfficient Storage ManagementPropagation through Transportable MediaLight-weight Management of Dynamic Replica SetsArbitrary Policy Choices
Rover ToolkitRover Toolkit
Set of Software Tools for Development of Mobile Applications
Two approaches:–Mobile-Transparent Applications–Mobile-Aware Applications
Goals:Goals: Minimize Dependence on
– Continuous Connectivity– Remotely Stored files
Optimize Utilization of Bandwidth Dynamic Division of Work
Previous WorkPrevious Work Cedar
– Check-in Check-out Data Sharing
Locus– Type-specific Conflict Resolution
Coda – Optimistic Concurrency Control– Pre-Fetching
Bayou – Tentative Data– Session Guarantees
Toolkit DesignToolkit Design
Client-Server architectureMobile Communication Support
– Re-locatable Dynamic Objects (RDO) Reduce Client/Server communication Update Shared Objects Code Shipping
– Queued Remote Procedure Call (QRPC) Non-Blocking Calls When Disconnected
Toolkit DesignToolkit Design
Application code & data are RDOsRover-Applications Interface Primary Functions
– Create Session – Import– Invoke– Export
RDOs are cahcedRDOs are lazily fetched
Toolkit DesignToolkit Design
Mobile Host Server
Client-SideApplication Rover
Library
NetworkScheduler
RDO Cache
QRPC Log
Import RDO
Export Log
RDO
Resolved Log
Object Conflict?
Modify/Resolve
Design IssuesDesign IssuesCommunication Scheduling Computation Relocation
– Separate application from data– Move computation/data: client server
Object Replication – Pre-fetchingConsistency
– Primary Copy, Tentative-Update Optimistic Concurrency Control
– Type-Specific Concurrency Control
ArchitectureArchitecture
Mobile Host Server
Network
App 1
Access Manager
ObjectCache
OperationLog
App3App 2
Network Scheduler
App 1
Access Manager
ObjectCache
OperationLog
App 2
Network Scheduler
App3
Rover starts as a minimal kernelFailure Recovery – Access ManagerLog SizeBatching of QPRCsPromises – Callback User NotificationApplication-Specific Conflict Resolution
Implementation IssuesImplementation Issues
Single Server, Multiple ClientsDifferent Network OptionsTCP over wireless linksThree setups:
– Compressed or Batched QRPCs– Mobile-Transparent Application – Mobile-Aware Applications
ExperimentsExperiments
Experiments - IIExperiments - II
05
10152025303540
Tim
e (
ms
ec
)
Ethernet WaveLAN
ISDN(128)
ISDN (64) 19.2CSLIP
9.6Cellular
Average time for 1 Null QRPCCompressed batched
Compressed single
UncomppressedoverlappedUncompressed single
Experiments - IIIExperiments - III
0
100
200
300
400
500
Tim
e (
se
c)
Ethernet WaveLAN
ISDN(128)
ISDN (64) 19.2CSLIP
9.6Cellular
(Mobile-Transparent) Time to Display 10 Web Pages
Netscape Netscape+Rover
-2
0
2
4
6
8
Sp
ee
d U
p
Ethernet WaveLAN
ISDN(128)
ISDN (64) 19.2CSLIP
9.6Cellular
(Mobile-Aware Applications) Speed up
Rover Irolo Rover Webcal Rover Exmh
Experiments - IVExperiments - IV
QRPC benefits: – RPCs are scheduled, batched, compressed– Increased Network Performance
RDOs migrate functionality – Minimize Data Transfer
Porting of Applications to Rover is relatively easy
Measurements show significant improvement from both approaches
Rover - SummaryRover - Summary
Topics for DiscussionTopics for DiscussionAre there ‘missing’ features?
– What if the semantics are not that ‘strong’?– Or, if the uncertainty about data values is not
accepted?– Should Rover support some replication service?
Do we really know what should be an ‘interesting’ mobile application ?