We have a DREAM: Distributed Reactive Programming with Consistency Guarantees - DEBS 2014

1. We Have a DREAM
Distributed Reactive Programming
with Consistency Guarantees
A. Margara
USI
Lugano
G. Salvaneschi
Technische Universitat
Darmstadt

2. 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

3. Reactive Systems
GUI
Monitoring / Control
System

4. Event-Based Programming
boolean 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
functions
Callback
functions
StateState
Control
statements
Control
statements

5. Reactive Programming
alarm.active :=
detector.intensity > 0.5 && sensor.temp > 45;
detector.intensity sensor.temp
alarm.active
Observable
variables
Observable
variables
Reactive
variables
Reactive
variables
Expression /
constraint
Expression /
constraint

6. Reactive Programming

7. 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

8. 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
AA
B = f(A)B = f(A)
C = g(A)C = g(A)
D = h(B, C)D = h(B, C)

9. 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
AA
B = f(A, A’)B = f(A, A’)
C = g(A, A’)C = g(A, A’)
A’A’

10. 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

11. 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

12. DREAM: API
Abstract class
Observable methods
(used in expressions that
define reactive variables)

13. DREAM: API

14. DREAM: Implementation
Watcher
B
B
B
B
B
B
R
c
c
c
c
c
c
c
c
c
c
cc
CommunicationManager
Reactive
Object
Observable
Object
Subscribe
Notify Advertise/Notify
Acyclic
network of
brokers
Acyclic
network of
brokers
Client
Library
Client
Library

15. DREAM: Implementation
• Observable object
creation
– An advertisement is
flooded to all the
brokers in the network
Watcher
B
B
B
B
B
B
R
c
c
c
c
c
c
c
c
c
c
cc
CommunicationManager
Reactive
Object
Observable
Object
Subscribe
Notify Advertise/Notify

16. 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
B
B
B
R
c
c
c
c
c
c
c
c
c
c
cc
CommunicationManager
Reactive
Object
Observable
Object
Subscribe
Notify Advertise/Notify

17. 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
B
B
B
R
c
c
c
c
c
c
c
c
c
c
cc
CommunicationManager
Reactive
Object
Observable
Object
Subscribe
Notify Advertise/Notify

18. Consistency Guarantees
• Causal semantics
• Glitch-free semantics
• Atomic semantics

19. 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

20. 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
AA
B = 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!

21. 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
AA
B = f(A, A’)B = f(A, A’)
C = f(A, A’)C = f(A, A’)
A’A’

22. Evaluation
• Goal
– Comparison of consistency guarantees
– Under different scenarios
• Metrics
– Updates propagation delay
– Network traffic

23. 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

24. 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

25. Locality of Expressions
Delay Traffic

26. Spurious Notifications
AA
B = f(A)B = f(A)
C = g(A)C = g(A)
D = h(B, C)D = h(B, C) …

27. Size of Reactive Graph
Delay Traffic

28. Conclusions
• First system providing
– Distributed reactive programming
– With flexible consistency guarantees
• Study of benefits/cost
• Try it!
– www.inf.usi.ch/postdoc/margara

29. (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

30. www.inf.usi.ch/postdoc/margara