Requirements on message-based interactions can be formalized as an interface contract that specifies constraints on the sequence of possible messages that can be exchanged by multiple parties. At runtime, each peer can monitor incoming messages and check that the contract is correctly being followed by their respective senders. We introduce cooperative runtime monitoring, where a recipient “delegates” its monitoring task to the sender, which is required to provide evidence that the message it sends complies with the contract. In turn, this evidence can be quickly checked by the recipient, which is then guaranteed of the sender’s compliance to the contract without doing the monitoring computation by itself. A particular application of this concept is shown on web services, where service providers can monitor and enforce contract compliance of third-party clients at a small cost on the server side, while avoiding to certify or digitally sign them.

1. Fonds de recherche
sur la nature
et les technologies NSERC
CRSNG
Sylvain Hallé

2. For more information
Visit my web site
www.leduotang.com/sylvain
Sylvain Hallé

3. Context
The
Client
Sylvain Hallé 2

4. Context
The
Server
The
Client
Sylvain Hallé 2

5. Context
The
Server
A
The
Client
Sylvain Hallé 2

6. Context
The Request
Server message
A
The
Client
Sylvain Hallé 2

7. Context
The
Server
A
B
The
Client
Sylvain Hallé 2

8. Context
The
Server
A
Response
message B
The
Client
Sylvain Hallé 2

9. Context
Alphabet (A)
Set of possible messages
Sylvain Hallé 3

10. Context
Alphabet (A)
Set of possible messages
Trace (A*)
Sequence of messages
Sylvain Hallé 3

11. Context
Alphabet (A)
Set of possible messages
Trace (A*)
Sequence of messages
State
Abstraction of a trace
Sylvain Hallé 3

12. Context
Transition function (d
)
d
Sylvain Hallé 3

13. Context
Transition function (d
)
d
A
Sylvain Hallé 3

14. Context
Transition function (d
)
d
A s
S
Sylvain Hallé 3

15. Context
Transition function (d
)
d s’
A s
S
Sylvain Hallé 3

16. Context
Transition function (d
)
d s’
Æ
A s
S
Sylvain Hallé 3

17. Context
Transition function (d
)
dS ®
:A´ S
d an) º (... d
(a0a1 ... d (s0, a0)...))
(an, d
d s’
Æ
A s
S
Sylvain Hallé 3

18. Context
Transition function (d
)
dS ®
:A´ S
d an) º (... d
(a0a1 ... d (s0, a0)...))
(an, d
Interface contract (k)
Defines valid traces
d s’
k {T, F}
: A* ®
Æ
A s
S
Sylvain Hallé 3

19. Context
Transition function (d
)
dS ®
:A´ S
d an) º (... d
(a0a1 ... d (s0, a0)...))
(an, d
Interface contract (k)
Defines valid traces
d s’
k {T, F}
: A* ®
Æ
k n)= T
(a0a1...a
A s
S
Sylvain Hallé 3

20. Context
Transition function (d
)
dS ®
:A´ S
Û
d an) º (... d
(a0a1 ... d (s0, a0)...))
(an, d
Interface contract (k)
Defines valid traces
d s’
k {T, F}
: A* ®
Æ
k n)= T
(a0a1...a
A s
S
Sylvain Hallé 3

21. Context
Transition function (d
)
dS ®
:A´ S
Û
d an) º (... d
(a0a1 ... d (s0, a0)...))
(an, d
Interface contract (k)
Defines valid traces
d s’
k {T, F}
: A* ®
Æ
k n)= T
(a0a1...a
A s
S d a n) ¹
(a0a1 ... Æ
Sylvain Hallé 3

22. A general framework
Server
A Message
Client
Interface contract
Sylvain Hallé 4

23. A general framework
Iterator
class Method
A call
Java
program
Two calls of the next() method must be
separated by at least one occurrence of
hasNext().
Sylvain Hallé 4

24. A general framework
web XML
service A message
Ajax web
client
If CartClear is invoked, no CartModify or
CartRemove can occur before a new
CartAdd.
Sylvain Hallé 5

25. Contract violations
What happens when the contract is violated?
- Error messages
- Non-sensical data returned
- Compensation mechanisms
- Wasted processing time
- Security breaches
- Etc.
Sylvain Hallé 6

26. The big question
Prevent
contract
violations
Sylvain Hallé 7

27. Current solutions
1. A priori certification
A trustworthy authority
assesses the client’s
compliance to the contract...
Testing, static
verification
etc.
Sylvain Hallé 8

28. Current solutions
1. A priori certification
A trustworthy authority
assesses the client’s
compliance to the contract...
...and grants a digital
certificate
Sylvain Hallé 8

29. Current solutions
1. A priori certification
A+
The service needs a certificate to
start an exchange with a client
Sylvain Hallé 8

30. Current solutions
1. A priori certification
A+
The service needs a certificate to
start an exchange with a client
Example: iPhone app certification
Sylvain Hallé 8

31. Current solutions
1. A priori certification
Z+
Problem: the client can change after
certification
iPhone jailbreaking,
Javascript prototype hijacking, ...
Sylvain Hallé 8

32. Current solutions
2. Server-side Runtime
Monitoring
A separate process checks
each incoming message...
A
Sylvain Hallé 9

33. Current solutions
2. Server-side Runtime
Monitoring
A separate process checks
A each incoming message...
The message is relayed to the application
proper when it complies with the contract
Sylvain Hallé 9

34. Current solutions
2. Server-side Runtime
Monitoring
A separate process checks
each incoming message...
...and is discarded when it violates the
contract
Sylvain Hallé 9

35. Current solutions
2. Server-side Runtime
Monitoring
Problem: computational load on the server
side
Sylvain Hallé 9

36. Current solutions
3. Client-side Runtime
Monitoring
Each client has a separate
process that validates its
messages before sending them
A
Sylvain Hallé 10

37. Current solutions
3. Client-side Runtime
Monitoring
Z
Z
Z
Problem: server has no guarantee that
monitoring actually takes place
Sylvain Hallé 10

38. Goal
Processing savings of
client-side monitoring
Guarantees of server-side
monitoring
Sylvain Hallé 11

39. Goal
COOPERATIVE
RUNTIME MONITORING
Processing savings of
client-side monitoring
Guarantees of server-side
monitoring
Sylvain Hallé 11

40. Goal
Complete
Guarantees
None
0 Computational 100%
savings
Sylvain Hallé 12

41. Goal
Complete
Guarantees
None Client-side
monitoring
0 Computational 100%
savings
Sylvain Hallé 12

42. Goal
Complete
Server-side
monitoring
Guarantees
None Client-side
monitoring
0 Computational 100%
savings
Sylvain Hallé 12

43. Goal
Complete
Server-side
monitoring
?
Guarantees
None Client-side
monitoring
0 Computational 100%
savings
Sylvain Hallé 12

44. Goal
Complete
Server-side
monitoring
Guarantees
None Client-side
monitoring
0 Computational 100%
savings
Sylvain Hallé 12

45. Goal
No way
Complete to preserve
complete
guarantees
Server-side
monitoring
Guarantees
None Client-side
monitoring
0 Computational 100%
savings
Sylvain Hallé 12

46. Goal
Complete
Server-side
monitoring
Guarantees
None Client-side
monitoring
0 Computational 100%
savings
Sylvain Hallé 12

47. Goal
Potential for
cooperation
Complete
Server-side
monitoring
Guarantees
None Client-side
monitoring
0 Computational 100%
savings
Sylvain Hallé 12

48. Cooperative runtime monitoring
Both the server- and client-
side monitors maintain the
current state of the message
exchange
s
s
Sylvain Hallé 13

49. Cooperative runtime monitoring
From its current state (s) and
new message (A), the client-
side monitor computes (g )...
A
Sylvain Hallé 13

50. Cooperative runtime monitoring
From its current state (s) and
new message (A), the client-
side monitor computes (g )...
s, s’,
A)
g=
( ()
s’ The new contract state
A ‘‘proof’’ that A is a valid extension
of the message exchange
Sylvain Hallé 13

51. Cooperative runtime monitoring
The proof is sent with the
message
A+
Sylvain Hallé 13

52. Cooperative runtime monitoring
From its current state (s),
incoming message (A) and
proof ( ), the server-side
monitor computes (m and n)...
Sylvain Hallé 13

53. Cooperative runtime monitoring
From its current state (s),
incoming message (A) and
proof ( ), the server-side
monitor computes (m and n)...
A,=
m T/F
()
n s’
s,
(= )
T/F If the proof is consistent with the
accompanying message
s’ The new contract state
Sylvain Hallé 13

54. Cooperative runtime monitoring
Both sides agree on the new current state (s’)
s’
s’
Sylvain Hallé 14

55. Cooperative runtime monitoring
Both sides agree on the new current state (s’)
The client computes
s’ it from s and A
s’
Sylvain Hallé 14

56. Cooperative runtime monitoring
Both sides agree on the new current state (s’)
The client computes
s’ it from s and A
s’
The server computes
it from s and
Sylvain Hallé 14

57. Requirements
A+
s , s’,
g=A)
( () A , =( =
m T/F n s’
() s,)
Sylvain Hallé 15

58. Requirements
A+
s , s’,
g=A)
( () A , =( =
m T/F n s’
() s,)
1. The proof must be unspoofable
If A is not a valid continuation from state s, then for
any , either m F or n ?
A,=s,=
() ( )
2. The proof must be equivalent to contract monitoring
If A is a valid continuation from state s to state s’, then
, m T and n s’
A,= ( =
() s, )
3. Checking the proof must be easy (i.e. polynomial)
Sylvain Hallé 15

59. Requirements
A+
s , s’,
g=A)
( () A , =( =
m T/F n s’
() s,)
1. The proof must be unspoofable
If A is not a valid continuation from state s, then for
any , either m F or n ?
A,=s,=
() ( )
2. The proof must be equivalent to contract monitoring
If A is a valid continuation from state s to state s’, then
, m T and n s’
A,= ( =
() s, )
3. Checking the proof must be easy (i.e. polynomial)
Sylvain Hallé 15

60. Requirements
A+
s , s’,
g=A)
( () A , =( =
m T/F n s’
() s,)
1. The proof must be unspoofable
If A is not a valid continuation from state s, then for
any , either m F or n ?
A,=s,=
() ( )
2. The proof must be equivalent to contract monitoring
If A is a valid continuation from state s to state s’, then
, m T and n s’
A,= ( =
() s, )
3. Checking the proof must be easy (i.e. polynomial)
Sylvain Hallé 15

61. Requirements
A+
s , s’,
g=A)
( () A , =( =
m T/F n s’
() s,)
1. The proof must be unspoofable
If A is not a valid continuation from state s (d Æ
(s,A) = ),
A,=s,=
then for any , either m F or n ?
() ( )
2. The proof must be equivalent to contract monitoring
If A is a valid continuation from state s to state s’, then
, m T and n s’
A,= ( =
() s, )
3. Checking the proof must be easy (i.e. polynomial)
Sylvain Hallé 15

62. Requirements
A+
s , s’,
g=A)
( () A , =( =
m T/F n s’
() s,)
1. The proof must be unspoofable
If A is not a valid continuation from state s (d Æ
(s,A) = ),
A,=s,=
then for any , either m F or n ?
() ( )
2. The proof must be equivalent to contract monitoring
If A is a valid continuation from state s to state s’, then
s , s’, ( )
A)
g =, m T and n s’
( () , = ( = A s, )
3. Checking the proof must be easy (i.e. polynomial)
Sylvain Hallé 15

63. Requirements
A+
s , s’,
g=A)
( () A , =( =
m T/F n s’
() s,)
1. The proof must be unspoofable
If A is not a valid continuation from state s (d Æ
(s,A) = ),
A,=s,=
then for any , either m F or n ?
() ( )
2. The proof must be equivalent to contract monitoring
If A is a valid continuation from state s to state s’, then
s , s’, ( )
A)
g =, m T and n s’
( () , = ( = A s, )
3. Checking the proof must be easy (i.e. polynomial)
Þ be in NP
mmust
and n
Sylvain Hallé 15

64. Expressing an interface contract
LTL formula = assertion on a trace (of messages)
Ga "always a"
Xa "the next message is a"
Fa "eventually a"
aWb "a until b
abacdcbaqqtam...
G (a ®
X b) FALSE ØW c
(q Ú
t) TRUE
Gerth, Peled, Vardi, Wolper (PSTV 1995): on-the-fly runtime
monitoring algorithm for LTL
Sylvain Hallé 16

65. Classical LTL runtime monitoring
Algorithm overview:
1. An LTL formula is decomposed into nodes of the form
sub-formulas that sub-formulas that must
must be true now be true in the next state
Sylvain Hallé 17

66. Classical LTL runtime monitoring
Algorithm overview:
1. An LTL formula is decomposed into nodes of the form
sub-formulas that sub-formulas that must
must be true now be true in the next state
Example:
Sylvain Hallé 17

67. Classical LTL runtime monitoring
2. Negations pushed inside (classical identities +
dual of U = V)
3. At the leaves, G atoms + negations of atoms:
contains
we evaluate them
Verdict:
! All leaves contain FALSE: formula is false
! A leaf is empty: formula is true
! Otherwise:
4. Next event: D into G continue
copied and we
Sylvain Hallé 18

68. Classical LTL runtime monitoring
Example: G
G (p Ù F s))
(X q Ú
1
2
X
p
F1 F2
p
Sylvain Hallé 19

69. Classical LTL runtime monitoring
Example: G
G (p Ù F s))
(X q Ú
If p is true and s is false in the 1
current message m, then...
2
X
p
p
F1 F2
p
s p
Sylvain Hallé 20

70. Intuition for g
s
1. This algorithm computes G
d s’
(s,A) =
1
2
X
p
p
s’ F1 F2
p
s p
s’
Sylvain Hallé 21

71. Intuition for g
1. This algorithm computes G
d s’
(s,A) =
2. The proof is the
path to each valid leaf 1
= 2
X
p
p
F1 F2
p
s p
Sylvain Hallé 21

72. Intuition for g
1. This algorithm computes G
d s’
(s,A) =
2. The proof is the
path to each valid leaf 1
= G 2
X
p
p
F1 F2
p
s p
Sylvain Hallé 21

73. Intuition for g
1. This algorithm computes G
d s’
(s,A) =
2. The proof is the
path to each valid leaf 1
= G, Ù 2
X
p
p
F1 F2
p
s p
Sylvain Hallé 21

74. Intuition for g
1. This algorithm computes G
d s’
(s,A) =
2. The proof is the
path to each valid leaf 1
= G, Ù
,Ú
1 2
X
p
p
F1 F2
p
s p
Sylvain Hallé 21

75. Intuition for g
1. This algorithm computes G
d s’
(s,A) =
2. The proof is the
path to each valid leaf 1
= G, Ù
,Ú
1, X 2
X
p
p
F1 F2
p
s p
Sylvain Hallé 21

76. Intuition for g
1. This algorithm computes G
d s’
(s,A) =
2. The proof is the
path to each valid leaf 1
= G, Ù p
,Ú
1, X, 2
X
p
p
F1 F2
p
s p
Sylvain Hallé 21

77. Intuition for g
1. This algorithm computes G
d s’
(s,A) =
2. The proof is the
path to each valid leaf 1
= G, Ù p
,Ú1, X, 2
X
{q, G (p Ù F s))}
(X q Ú
p
p
F1 F2
p
s p
Sylvain Hallé 21

78. Intuition for g
1. This algorithm computes G
d s’
(s,A) =
2. The proof is the
path to each valid leaf 1
= G, Ù p
,Ú1, X, 2
X
{q, G (p Ù F s))}
(X q Ú
p
+ p
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú F1 F2
p
s p
Sylvain Hallé 21

79. Intuition for g
1. This algorithm computes G
d s’
(s,A) =
2. The proof is the
path to each valid leaf 1
= G, Ù p
,Ú1, X, 2
X
{q, G (p Ù F s))}
(X q Ú
p
+ p
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú F1 F2
p
3. The combination gives us
s p
s , s’,
g= A)
( ()
Sylvain Hallé 21

80. Intuition for m
A+
s , s’,
g=A)
( () A , =( =
m T/F n s’
() s,)
Given a message (A) and a proof ( ), one can check that the
atoms in the paths are indeed true in the message...
= G, Ùp,Ú, X,
1
{q, G (p Ù F s))}
(X q Ú Is p true
in A?
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
...this computes
m ()A,
Sylvain Hallé 22

81. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
G (p Ù F s))
(X q Ú
= G, Ù p
,Ú1, X,
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23

82. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
G (p Ù F s))
G (X q Ú
= G Ùp
G, , Ú
, X,
1
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23

83. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
G (p Ù F s))
(X q Ú
= G, Ù p
,Ú1, X,
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23

84. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
G (p Ùs))
ÙF
(X q Ú
= G, Ù
Ùp,Ú1, X,
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23

85. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
,qÚ
G (p Ù F s))
(X
= G, Ù p
,Ú1, X,
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23

86. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
, qÚ
G (p Ù F s))
(X Ú
= ,Ú
G, Ù pÚ1, X,
1
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23

87. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
,q
G (p Ù
(X
= G, Ù p
,Ú1, X,
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23

88. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
,q
G (p ÙX
(X
= G, Ù p
,Ú1, X
X,
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23

89. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
G (p Ù
(X q q
= G, Ù p
,Ú1, X,
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23

90. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
p q
= G, Ùp,Ú1, X,
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23

91. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
q
= G, Ù ,Ú1, X,
{q, G (p Ù F s))}
(X q Ú
+
G, Ù p
,Ú2, F2,
{F q, G (p Ù F s))}
(X q Ú
Sylvain Hallé 23

92. Intuition for n
From an initial state (s), one can ‘‘peel off’’ the formula
according to the path given by the proof...
q
= G, Ù,Ú , X,
1
...if the operation comes to
{q, G (p Ù F s))}
(X q Ú
an end, we accept the leaf
+
G, Ù p
,Ú
given in as the resulting
2, F2,
{F q, G (p Ù F s))}
(X q Ú end state s’
...this computes
n s’
s,
(= )
Sylvain Hallé 23

93. What about complexity?
number of witnesses < total number of leaves
<
s,
(n <
() < (g)
) (s,A)
Does not expand
‘‘dead-end’’ branches
Sylvain Hallé 24

94. What about complexity?
number of witnesses < total number of leaves
<
s,
(n <
() < (g)
) (s,A)
number of witnesses total number of leaves
(n s,
() ) (g)(s,A)
Sylvain Hallé 24

95. What about complexity?
number of witnesses < total number of leaves
<
s,
(n <
() < (g)
) (s,A)
number of witnesses total number of leaves
(n s,
() ) (g)(s,A)
check the proof compute the proof
Þ
Sylvain Hallé
{
Non-branching LTL
No gain...
Solution: restrict LTL to fragment that produces at most one
witness at every step
24

96. Non-branching LTL
Follows three conditions:
Sylvain Hallé 25

97. Non-branching LTL
Follows three conditions:
1. ( Ú
. (
. .
. .
) .
)
Sylvain Hallé 25

98. Non-branching LTL
Follows three conditions:
No temporal operator
1. ( Ú
. (
. .
. .
) .
)
Sylvain Hallé 25

99. Non-branching LTL
Follows three conditions:
No temporal operator
1. ( Ú
. (
. .
. .
) .
) 2. F ( ... )
Sylvain Hallé 25

100. Non-branching LTL
Follows three conditions:
No temporal operator
1. ( Ú
. (
. .
. .
) .
) 2. F ( ... )
Sylvain Hallé 25

101. Non-branching LTL
Follows three conditions:
No temporal operator
1. ( Ú
. (
. .
. .
) .
) 2. F ( ... ) 3. ( U (
.
. .
. .
) . )
Sylvain Hallé 25

102. Non-branching LTL
Follows three conditions:
No temporal operator
1. ( Ú
. (
. .
. .
) .
) 2. F ( ... ) 3. ( U (
.
. .
. .
) . )
Sylvain Hallé 25

103. Non-branching LTL
Follows three conditions:
No temporal operator
1. ( Ú
. (
. .
. .
) .
) 2. F ( ... ) 3. ( U (
.
. .
. .
) . )
Sylvain Hallé 25

104. Non-branching LTL
Follows three conditions:
No temporal operator
1. ( Ú
. (
. .
. .
) .
) 2. F ( ... ) 3. ( U (
.
. .
. .
) . )
Theorem: a non-branching LTL formula produces a proof ( )
linear in the length of the interface contract (see the paper!)
Sylvain Hallé 25

105. Non-branching LTL
Follows three conditions:
No temporal operator
1. ( Ú
. (
. .
. .
) .
) 2. F ( ... ) 3. ( U (
.
. .
. .
) . )
Theorem: a non-branching LTL formula produces a proof ( )
linear in the length of the interface contract (see the paper!)
Non-branching LTL contracts can be efficiently enforced
Þ
through cooperative runtime monitoring
Sylvain Hallé 25

106. Experimental results
Sylvain Hallé 26

107. Experimental results
A
Sylvain Hallé 26

108. Experimental results
s, s’,
A)
g=
( ()
Sylvain Hallé 26

109. Experimental results
s, s’,
A)
g=
( ()
= 5.08 ms
Sylvain Hallé 26

110. Experimental results
A+
= 5.08 ms
Sylvain Hallé 26

111. Experimental results
A,=
m T/F
()
n s’
s,
(= )
= 5.08 ms
Sylvain Hallé 26

112. Experimental results
A,=
m T/F
()
n s’
s,
(= )
= 0.35 ms
= 5.08 ms
Sylvain Hallé 26

113. Experimental results
= 0.35 ms
= 5.08 ms
Server is spared of 90%
of the computation
Sylvain Hallé 26

114. Experimental results
Complete
Server-side
monitoring
Guarantees
None Client-side
monitoring
0 Computational 100%
savings
Sylvain Hallé 27

115. Experimental results
Complete
Cooperative
Server-side monitoring
monitoring
Guarantees
None Client-side
monitoring
0 Computational 100%
savings
Sylvain Hallé 27

116. Experimental results
Expressiveness
Complete
Cooperative
Server-side monitoring
monitoring
Guarantees
None Client-side
monitoring
0 Computational 100%
savings
Sylvain Hallé 27

117. Experimental results
Expressiveness
Complete
Cooperative
Server-side monitoring
monitoring
Guarantees
Non-
branching LTL Client-side
None monitoring
0 Computational 100%
savings
Sylvain Hallé 27

118. Experimental results
Expressiveness
Complete
Cooperative
Server-side monitoring
monitoring
Guarantees
LTL
Non-
branching LTL Client-side
None monitoring
0 Computational 100%
savings
Sylvain Hallé 27

119. Experimental results
Expressiveness
Complete
Cooperative
Server-side monitoring First-
monitoring order logic
Guarantees
LTL
Non-
branching LTL Client-side
None monitoring
0 Computational 100%
savings
Sylvain Hallé 27

120. Experimental results
Theoretical
upper bound
Expressiveness
Complete
Cooperative
Server-side monitoring First-
monitoring order logic
Guarantees
LTL
Non-
branching LTL Client-side
None monitoring
0 Computational 100%
savings
Sylvain Hallé 27

121. Take-home points
Sylvain Hallé 28

122. Take-home points
1. An interface contract specifies valid sequences of
‘‘messages’’ between a client and a server
.
Sylvain Hallé 28

123. Take-home points
1. An interface contract specifies valid sequences of
‘‘messages’’ between a client and a server
.
2. Cooperative runtime monitoring allows the enforcement of
the contract to be split between both parties
.
Sylvain Hallé 28

124. Take-home points
1. An interface contract specifies valid sequences of
‘‘messages’’ between a client and a server
.
2. Cooperative runtime monitoring allows the enforcement of
the contract to be split between both parties
..
3. For a fragment of Linear Temporal Logic, empirical tests
show that 90% of the work can be outsourced to the client...
Sylvain Hallé 28

125. Take-home points
1. An interface contract specifies valid sequences of
‘‘messages’’ between a client and a server
.
2. Cooperative runtime monitoring allows the enforcement of
the contract to be split between both parties
..
3. For a fragment of Linear Temporal Logic, empirical tests
show that 90% of the work can be outsourced to the client...
.
4. ...while preserving the same guarantees as with
server-side monitoring
Sylvain Hallé 28

126. Take-home points
1. An interface contract specifies valid sequences of
‘‘messages’’ between a client and a server
.
2. Cooperative runtime monitoring allows the enforcement of
the contract to be split between both parties
..
3. For a fragment of Linear Temporal Logic, empirical tests
show that 90% of the work can be outsourced to the client...
.
4. ...while preserving the same guarantees as with
server-side monitoring
.
5. This is a 3D problem: guarantees, computational
load and expressiveness can be modulated
Sylvain Hallé 28

127. For more information
Visit my web site
www.leduotang.com/sylvain
Sylvain Hallé