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

856 views
626 views

Published on

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

Published in: Software
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
856
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Examples of reactive systems are GUI, in which the system receives an input from the user, processes it, and reacts to it, by applying some changes to the interface.
    Similarly, in monitoring and control system, a processing module receives events from the external environment (e.g., sensor readings) and reacts to them (e.g., triggering an alarm in case of danger).
  • Need to define variables to keep state information
    Variables can be modified in several callback methods (easy to loose data dependency information)
    Check and control statement in several code locations (e.g., activate / deactivate the alert)
  • You can set the visibility to LOCAL
    Or to GLOBAL
    You can use remote observable to define new reactive objects
    You can call normal methods or register a listener for a specific method
    You can define observable reactive
  • Causal allows local processing of local events (no need to contact brokers to check for glitch-freedom violations)
    Much lower delat and traffic
    Atomic requires additional communication with a granting service to ensure atomicity of propagation
    Significant differences in delay and traffic when moving from centralized to distributed, especially for protocols that need to communicate with the broker network
  • Both delay and traffic decrease with the locality of expression.
    Traffic goes to 0 with the causal consistency protocol (no need to communicate)
    Interestingly, with a limited locality, the causal consistency protocol produces MORE traffic. This is because of the propagation of spurious updates.
  • We have a DREAM: Distributed Reactive Programming with Consistency Guarantees - DEBS 2014

    1. 1. We Have a DREAM Distributed Reactive Programming with Consistency Guarantees A. Margara USI Lugano G. Salvaneschi Technische Universitat Darmstadt
    2. 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. 3. Reactive Systems GUI Monitoring / Control System
    4. 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. 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. 6. Reactive Programming
    7. 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. 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. 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. 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. 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. 12. DREAM: API Abstract class Observable methods (used in expressions that define reactive variables)
    13. 13. DREAM: API
    14. 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. 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. 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. 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. 18. Consistency Guarantees • Causal semantics • Glitch-free semantics • Atomic semantics
    19. 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. 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. 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. 22. Evaluation • Goal – Comparison of consistency guarantees – Under different scenarios • Metrics – Updates propagation delay – Network traffic
    23. 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. 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. 25. Locality of Expressions Delay Traffic
    26. 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. 27. Size of Reactive Graph Delay Traffic
    28. 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. 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. 30. www.inf.usi.ch/postdoc/margara

    ×