Distributed System Contract Monitoring

Abstract

The use of behavioural contracts, to specify, regulate and verify systems, is particularly relevant to runtime monitoring of distributed systems. System distribution poses major challenges to contract monitoring, from monitoring-induced information leaks to computation load balancing, communication overheads and fault-tolerance. We present mDPi, a location-aware process calculus, for reasoning about monitoring of distributed systems. We define a family of Labelled Transition Systems for this calculus, which allow formal reasoning about different monitoring strategies at different levels of abstractions. We also illustrate the expressivity of the calculus by showing how contracts in a simple contract language can be synthesised into different mDPi monitors.

Synthesising Correct Concurrent Runtime Monitors

“…Distributed monitoring can also be used to increase the expressivity of our tool so as to handle correctness properties for distributed programs. However, this poses a departure from our setting because the unique trace described by our framework would be replaced by separate independent traces at each location, where the lack of a total ordering of events may prohibit the detection of certain violations [19]. 27 …”

“…Their setting is however different from ours: their systems do not assume a global clock and monitoring work over partially ordered traces (one for each location). Monitoring in the absence of global clocks is also considered in [19], where they develop bisimulation-based coinductive techniques to reason about monitored systems. Crucially, none of these works considers issues relating to the correctness of monitor synthesis studied in this paper.…”

“…Asynchronous monitoring has also been used in other RV tools, e.g., [14,17], and has proved to be less intrusive and easier to instrument than synchronous monitoring setups. It is also the more feasible alternative when monitoring distributed systems [19,16]. More importantly, though, it still allows us to investigate the main issues arising from the correctness setup outlined in (1), and we expect most of the issues investigated to carry over in a straightforward fashion to purely synchronous settings.…”

On Verifying Hennessy-Milner Logic with Recursion at Runtime

“…The first approach is, in general, more popular and tends to produce specifications that are closely related to the monitors that check for them (e.g., RE and automata in [15,23]), thus facilitating aspects such as monitor correctness. On the other hand, the second approach does not hinder the expressive power of the logic.…”

“…The first approach is to restrict the expressive power of the correctness specifications: typically, one either limits specifications to descriptions of finite traces such as regular expressions (RE) [12,15], or else redefines the semantics of existing logics (e.g., LTL) so as to reflect the limitations of the runtime setting [13,5,7,6]. The second approach is to leave the semantics of the specification logic unchanged, and study which subsets of the logic can be verified at runtime [17,24,11,16].…”