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