Constructive protocol specification using Cicero

Abstract

New protocols are often useful, but are hard to implement well. Protocol synthesis is a solution, but synthesized protocols can be slow. Implementing protocols will be even more challenging in the future, since we expect that more advanced communication functionality will be moved from applications into protocol implementations to reduce application development effort. This trend can be seen from the recent enhancements of RPC to include semantics for supporting group communication, transactions, fault-tolerance, etc.[1], [2], [3], [4]. Protocol developers will also be challenged to provide correct and efficient protocol implementations that manage numerous concurrent I/O channels, and to increase protocol throughput to meet real-time requirements. These requirements demand better language support to facilitate precise control of multiple-thread interactions, and aggressive exploitation of parallelism in protocol execution. Protocol synthesis is also required for dynamic creation of protocol adapters in heterogeneous environments [5], [6]. This paper describes Cicero, a set of language constructs to allow constructive protocol specifications. Unlike other protocol specification languages, Cicero gives programmers explicit control over protocol execution, and facilitates both sequential and parallel implementations, especially for protocols above the transport-layer. It is intended to be used in conjunction with domain-specific libraries, and is quite different in philosophy and mode of use from existing protocol specification languages. A feature of Cicero is the use of event patterns [7] to control synchrony, asynchrony, and concurrency in protocol execution, which helps programmers build robust protocol implementations. Event-pattern driven execution also enables implementors to exploit parallelism of varying grains in protocol execution. Event patterns can also be translated into other formal models, so that existing verification techniques may be used.

Fault Detection for Timed FSM with Timeouts by Constraint Solving

“…They define timeouts and the next states to be reached if no input is applied before the timeouts expire; otherwise outputs defined by input/output transitions are produced. Although they express limited types of time constraints as compared to other timed FSMs [4], TFSMs-T have been used to specify reactive systems such as web applications [27] and protocols [26,22,13]. Logical faults in TFSMs-T correspond to unexpected outputs or unexpected state changes.…”