Download - We have a DREAM: Distributed Reactive Programming with Consistency Guarantees - DEBS 2014
We Have a DREAMDistributed Reactive Programming
with Consistency Guarantees
A. Margara
USI
Lugano
G. Salvaneschi
Technische Universitat
Darmstadt
DREAM
• DREAM: a middleware for distributed reactive programming
• Reactive programming is a novel programming model that simplifies the development of reactive systems– Systems that react to changes in the external
environment
Reactive Systems
GUIMonitoring / Control
System
Event-Based Programmingboolean highTemp;boolean smoke;
void onTempReading(TempEvent e ) {highTemp = e.getValue() > 45;if (highTemp && smoke) {
alert.start();}
}
void onSmokeReading(SmokeEvent e) {smoke = e.getIntensity() > 0.5;if (highTemp && smoke) {
alert.start();}
}
Callback functionsCallback functions
StateState
Control statements
Control statements
Reactive Programming
alarm.active := detector.intensity > 0.5 && sensor.temp > 45;
detector.intensity sensor.temp
alarm.active
Observable variables
Observable variables
Reactivevariables
Reactivevariables
Expression /constraint
Expression /constraint
Reactive Programming
Reactive Programming
• Data dependencies are explicit in the code– Code is more compact– Code is easier to read and understand
• The runtime is responsible for propagating changes and updating variables– Takes care of ensuring the correctness of the
propagation– With respect to some consistency guarantees
Consistency Guarantees
• Depending on the propagation strategy– D could be updated with a new value of B and an
old value of C• Temporary inconsistency glitch
AAB = f(A)B = f(A)
C = g(A)C = g(A)D = h(B, C)D = h(B, C)
Consistency Guarantees
• Depending on the propagation strategy– B and C could see updates from A and A’ in
different orders• Violation of the atomicity of propagation
AAB = f(A, A’)B = f(A, A’)
C = g(A, A’)C = g(A, A’)A’A’
Existing Work
• RP has been studied in centralized scenarios– Several systems include propagation strategies
that ensure glitch-freedom
• Distributed RP received little attention– E.g., no system provides glitch-freedom/atomicity
in distributed settings
DREAM
• DREAM – Distributed REActive Middleware– Offers distributed RP in Java– Relies on a decentralized event-based middleware– Three levels of consistency guarantees• Causal
– Exactly once, FIFO and causal ordered delivery of updates
• Glitch free• Atomic
DREAM: API
Abstract class
Observable methods(used in expressions that define reactive variables)
DREAM: API
DREAM: Implementation
Watcher
B
B
B
BB
B
R
cc
cc c
cc
c
c
c cc
CommunicationManager
Reactive Object
Observable Object
SubscribeNotify Advertise/Notify
Acyclic network of
brokers
Acyclic network of
brokers
Client LibraryClient
Library
DREAM: Implementation
• Observable object creation– An advertisement is
flooded to all the brokers in the network
Watcher
B
B
B
BB
B
R
cc
cc c
cc
c
c
c cc
CommunicationManager
Reactive Object
Observable Object
SubscribeNotify Advertise/Notify
DREAM: Implementation
• Reactive object creation– One subscription for
each observable OB appearing in the expression
– Follows the reverse path of the advertisement up to the client in charge for OB
Watcher
B
B
B
BB
B
R
cc
cc c
cc
c
c
c cc
CommunicationManager
Reactive Object
Observable Object
SubscribeNotify Advertise/Notify
DREAM: Implementation
• Observable object (OB) update– An update event is
propagated– Matched and filtered at
each broker …– … to reach only
interested reactive objects• Defined starting from OB
Watcher
B
B
B
BB
B
R
cc
cc c
cc
c
c
c cc
CommunicationManager
Reactive Object
Observable Object
SubscribeNotify Advertise/Notify
Consistency Guarantees
• Causal semantics• Glitch-free semantics• Atomic semantics
Causal Semantics
• Node-to-node communication preserves ordering
• Processing preserves ordering• In absence of failures DREAM provides– Exactly once delivery– FIFO order of updates
• It can be demonstrated that– Acyclic network + FIFO order = causal order
Glitch-Freedom
• Brokers keep track of the dependency graph• In case of a potential glitch– They compute the set of updates a client should wait
for– They attach this information to the update events
AAB = f(A)B = f(A)
C = f(A)C = f(A)D = f(B, C)D = f(B, C)
Wait for C!
Wait for B!
Atomic Semantics
• Only one propagation is allowed at any point in time• Before starting a propagation a broker requests a
token to a special TGS– Requests get queued in the TGS– A new token is granted only when the previous
propagation is completed
AAB = f(A, A’)B = f(A, A’)
C = f(A, A’)C = f(A, A’)A’A’
Evaluation
• Goal– Comparison of consistency guarantees– Under different scenarios
• Metrics– Updates propagation delay– Network traffic
Default Scenario
Number of Brokers 10
Number of Clients 50
Number of Intermediate Brokers 50%
Link Latency 1-5ms
Number of Reactive Graphs 10
Depth of Reactive Graphs 5
Size of Reactive Expressions 2
Degree of Locality in Reactive Expressions 80%
Frequency of Changes per Observable 1 change/s
Advantages of Distribution
Delay (ms) Traffic (KB/s)
Central. Distrib. Central. Distrib.
Causal 4.77 4.76 68.3 69.8
Glitch-Free 29.53 17.18 205.4 130.9
Atomic 53.41 26.75 265.5 161.3
Locality of Expressions
Delay Traffic
Spurious Notifications
AAB = f(A)B = f(A)
C = g(A)C = g(A)D = h(B, C)D = h(B, C) …
Size of Reactive Graph
Delay Traffic
Conclusions
• First system providing– Distributed reactive programming– With flexible consistency guarantees
• Study of benefits/cost• Try it!– www.inf.usi.ch/postdoc/margara
(Current and) Future Work
• Adoption in mobile scenarios– Porting to Android– Definition of protocols to deal with (temporary) disconnections
• Improved expressiveness– Integration with the language
• Static type-checking of expressions – More types of observable/reactive objects
• Collections– Complex expressions
• Parameters, guards, historical values
• Improved performance– On-demand (pull-based) evaluation of reactive expressions
www.inf.usi.ch/postdoc/margara