On Specifying and Monitoring Epistemic Properties of Distributed Systems

1. On Specifying and Monitoring Epistemic Properties of Distributed Systems Koushik Sen Abhay Vardhan Gul Agha Grigore Rosu University of Illinois at Urbana-Champaign, USA

2. Software Reliability • Software Validation • Rigorous and Complete Methods • Model Checking • Theorem Proving • Infeasible for large-scale open distributed systems (Actors) • Non-determinism and Asynchrony • Testing • Widely used • Ad-Hoc • Good Test Coverage Required • Runtime Monitoring • Adds rigor to Testing

3. Centralized Monitoring Approach • Monitoring – Use Formal Methods in Testing • Synthesize light-weight Monitors from Specification • Automata, Rewriting-based Monitors • Instrument code to insert monitors • Execute instrumented code • Distributed System Monitoring • Global state is distributed • For every state update send state to a central monitor • Central monitor assembles them to form consistent execution traces • Sequence of global states • Monitor execution traces

4. An Example • Mobile node a requests certain value from node b • b computes the value and sends it to a • Property: no node receives a value from another node to which it had not sent a request

5. Centralized Monitoring Example “If a receives a value from b then b calculated the value after receiving request from a” valRcv → (valComputed  valReq) valReq valReq valComputed  valReq valRcv → (valComputed  valReq) (valComputed  valReq) b valComputed a valReq valRcv

6. Decentralized Monitoring Approach “If a receives a value from b then b calculated the value after receiving request from a” valRcv → @b((valComputed  @a(valReq))) valComputed  @a(valReq) @a(valReq) (valComputed  @a(valReq)) b valComputed a valReq valRcv valReq valRcv → @b((valComputed  @a(valReq)))

7. Past time Distributed Temporal Logic (pt-DTL) • Based on epistemic logic • [Aumann76][Meenakshi et al. 00] • Properties with respect to a process, say p

8. Leader Election Example “If a leader is elected then if the current process is a leader then, at its knowledge, none of the other processes (b and c) is a leader” elected → (state=leader → (@b(state ≠ leader) Æ @c(state ≠ leader)))

9. Leader Election (Stronger Property) • Every process must know the name of the process that has been elected leader elected → (let k=leaderName in (@b(leaderName = k) Æ @c(leaderName = k)))

10. Leader Election (Open System) • There are arbitrary number of processes whose names are not known before-hand elected → (let k=leaderName in @8 {j | j  i}(leaderName = k))

11. Extended Distributed Temporal Logic (xDTL) • Suitable for Open Distributed Systems (Actors) • Ids of all processes are not known before-hand • Quantification over processes • All processes satisfying a predicate • @8 {j | pred(j)} • Some process satisfying a predicate • @9 {j | pred(j)} • Value-binding (Increases Expressive Power) • let k = x in F • To refer to values in remote states

12. xDTL syntax • Fi ::= true | false | P(Ei) | : Fi | FiÆ Fi propositional | ¯ Fi | ¡ Fi | Fi | Fi S Fi temporal | @8 JFj | @9 JFj epistemic | let k = Ei in Fibinding • Ei ::= c | vi2 Vi | f(Ei) | k functional | @jEj epistemic

13. Interpretation of @8 JEj at process i p3 m4 m1 m2 p2 @ {1}(x=9) m3 p1 x=7 x=9

14. Monitoring Algorithm • Requirements • Should be fast so that online monitoring is possible • Little memory overhead • Additional messages sent should be minimal; ideally zero • Monitoring using KnowledgeVector • Maintain knowledge of global state at each process • Update knowledge with incoming messages • Attach knowledge with outgoing messages • At each process monitor local knowledge

15. Conclusion • Decentralized Technique to effectively verify open distributed systems at runtime • No extra message over-head for monitoring • xDTL can express interesting and useful safety properties of distributed systems • How to instrument code running on all processes so that monitoring can be done?