Cooperative Runtime Monitoring of LTL Interface Contracts (EDOC 2010)

740 views

Published on

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.

Published in: Technology, Education
1 Comment
0 Likes
Statistics
Notes
  • The slidecast feature on Slideshare is a bit messy. If you want to see slides in sync with the sound, please look below instead.

    <br /><object type="application/x-shockwave-flash" data="http://www.youtube.com/p/32DA6E9A869CA44D?hl=fr_FR&fs=1" width="350" height="288"><param name="movie" value="http://www.youtube.com/p/32DA6E9A869CA44D?hl=fr_FR&fs=1"></param><embed src="http://www.youtube.com/p/32DA6E9A869CA44D?hl=fr_FR&fs=1" width="350" height="288" type="application/x-shockwave-flash"></embed></object>
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Views
Total views
740
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
10
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide

Cooperative Runtime Monitoring of LTL Interface Contracts (EDOC 2010)

  1. 1. Cooperative Runtime Monitoring of LTL Interface Contracts Sylvain Hallé Université du Québec à Chicoutimi CANADA Fonds de recherche sur la nature et les technologies NSERC CRSNG Sylvain Hallé
  2. 2. Context The Client Sylvain Hallé 2
  3. 3. Context The Server The Client Sylvain Hallé 2
  4. 4. Context The Server A The Client Sylvain Hallé 2
  5. 5. Context The Request Server message A The Client Sylvain Hallé 2
  6. 6. Context The Server A B The Client Sylvain Hallé 2
  7. 7. Context The Server A Response message B The Client Sylvain Hallé 2
  8. 8. Context Alphabet (A) Set of possible messages Sylvain Hallé 3
  9. 9. Context Alphabet (A) Set of possible messages Trace (A*) Sequence of messages Sylvain Hallé 3
  10. 10. Context Alphabet (A) Set of possible messages Trace (A*) Sequence of messages State Abstraction of a trace Sylvain Hallé 3
  11. 11. Context Transition function (d ) d Sylvain Hallé 3
  12. 12. Context Transition function (d ) d A Sylvain Hallé 3
  13. 13. Context Transition function (d ) d A s S Sylvain Hallé 3
  14. 14. Context Transition function (d ) d s’ A s S Sylvain Hallé 3
  15. 15. Context Transition function (d ) d s’ Æ A s S Sylvain Hallé 3
  16. 16. Context Transition function (d ) dS ® :A´ S d an) º (... d (a0a1 ... d (s0, a0)...)) (an, d d s’ Æ A s S Sylvain Hallé 3
  17. 17. 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
  18. 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* ® Æ k n)= T (a0a1...a A s S Sylvain Hallé 3
  19. 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. 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 d a n) ¹ (a0a1 ... Æ Sylvain Hallé 3
  21. 21. A general framework Server A Message Client Interface contract Sylvain Hallé 4
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. The big question Prevent contract violations Sylvain Hallé 7
  26. 26. Current solutions 1. A priori certification A trustworthy authority assesses the client’s compliance to the contract... Testing, static verification etc. Sylvain Hallé 8
  27. 27. 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
  28. 28. Current solutions 1. A priori certification A+ The service needs a certificate to start an exchange with a client Sylvain Hallé 8
  29. 29. 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
  30. 30. Current solutions 1. A priori certification Z+ Problem: the client can change after certification iPhone jailbreaking, Javascript prototype hijacking, ... Sylvain Hallé 8
  31. 31. Current solutions 2. Server-side Runtime Monitoring A separate process checks each incoming message... A Sylvain Hallé 9
  32. 32. 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
  33. 33. 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
  34. 34. Current solutions 2. Server-side Runtime Monitoring Problem: computational load on the server side Sylvain Hallé 9
  35. 35. Current solutions 3. Client-side Runtime Monitoring Each client has a separate process that validates its messages before sending them A Sylvain Hallé 10
  36. 36. Current solutions 3. Client-side Runtime Monitoring Z Z Z Problem: server has no guarantee that monitoring actually takes place Sylvain Hallé 10
  37. 37. Goal Processing savings of client-side monitoring Guarantees of server-side monitoring Sylvain Hallé 11
  38. 38. Goal COOPERATIVE RUNTIME MONITORING Processing savings of client-side monitoring Guarantees of server-side monitoring Sylvain Hallé 11
  39. 39. Goal Complete Guarantees None 0 Computational 100% savings Sylvain Hallé 12
  40. 40. Goal Complete Guarantees None Client-side monitoring 0 Computational 100% savings Sylvain Hallé 12
  41. 41. Goal Complete Server-side monitoring Guarantees None Client-side monitoring 0 Computational 100% savings Sylvain Hallé 12
  42. 42. Goal Complete Server-side monitoring ? Guarantees None Client-side monitoring 0 Computational 100% savings Sylvain Hallé 12
  43. 43. Goal Complete Server-side monitoring Guarantees None Client-side monitoring 0 Computational 100% savings Sylvain Hallé 12
  44. 44. Goal No way Complete to preserve complete guarantees Server-side monitoring Guarantees None Client-side monitoring 0 Computational 100% savings Sylvain Hallé 12
  45. 45. Goal Complete Server-side monitoring Guarantees None Client-side monitoring 0 Computational 100% savings Sylvain Hallé 12
  46. 46. Goal Potential for cooperation Complete Server-side monitoring Guarantees None Client-side monitoring 0 Computational 100% savings Sylvain Hallé 12
  47. 47. Cooperative runtime monitoring Both the server- and client- side monitors maintain the current state of the message exchange s s Sylvain Hallé 13
  48. 48. Cooperative runtime monitoring From its current state (s) and new message (A), the client- side monitor computes (g )... A Sylvain Hallé 13
  49. 49. 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
  50. 50. Cooperative runtime monitoring The proof is sent with the message A+ Sylvain Hallé 13
  51. 51. Cooperative runtime monitoring From its current state (s), incoming message (A) and proof ( ), the server-side monitor computes (m and n)... Sylvain Hallé 13
  52. 52. 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
  53. 53. Cooperative runtime monitoring Both sides agree on the new current state (s’) s’ s’ Sylvain Hallé 14
  54. 54. 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
  55. 55. 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
  56. 56. Requirements A+ s , s’, g=A) ( () A , =( = m T/F n s’ () s,) Sylvain Hallé 15
  57. 57. 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
  58. 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. 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. 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 (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
  61. 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 s , s’, ( ) A) g =, m T and n s’ ( () , = ( = A s, ) 3. Checking the proof must be easy (i.e. polynomial) Sylvain Hallé 15
  62. 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) Þ be in NP mmust and n Sylvain Hallé 15
  63. 63. 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
  64. 64. 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
  65. 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 Example: Sylvain Hallé 17
  66. 66. 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
  67. 67. Classical LTL runtime monitoring Example: G G (p Ù F s)) (X q Ú 1 2 X p F1 F2 p Sylvain Hallé 19
  68. 68. 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
  69. 69. 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
  70. 70. 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
  71. 71. 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
  72. 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. 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, Ù ,Ú 1 2 X p p F1 F2 p s p Sylvain Hallé 21
  74. 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, X 2 X p p F1 F2 p s p Sylvain Hallé 21
  75. 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, Ù p ,Ú 1, X, 2 X p p F1 F2 p s p Sylvain Hallé 21
  76. 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 {q, G (p Ù F s))} (X q Ú p p F1 F2 p s p Sylvain Hallé 21
  77. 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 G, Ù p ,Ú2, F2, {F q, G (p Ù F s))} (X q Ú F1 F2 p s p Sylvain Hallé 21
  78. 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 3. The combination gives us s p s , s’, g= A) ( () Sylvain Hallé 21
  79. 79. 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
  80. 80. 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
  81. 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)) 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
  82. 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)) (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
  83. 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 Ù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
  84. 84. 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
  85. 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, 1 {q, G (p Ù F s))} (X q Ú + G, Ù p ,Ú2, F2, {F q, G (p Ù F s))} (X q Ú Sylvain Hallé 23
  86. 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 Ù (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
  87. 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 (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
  88. 88. 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
  89. 89. 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
  90. 90. 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
  91. 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, Ù,Ú , 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
  92. 92. What about complexity? number of witnesses < total number of leaves < s, (n < () < (g) ) (s,A) Does not expand ‘‘dead-end’’ branches Sylvain Hallé 24
  93. 93. 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
  94. 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) 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
  95. 95. Non-branching LTL Follows three conditions: Sylvain Hallé 25
  96. 96. Non-branching LTL Follows three conditions: 1. ( Ú . ( . . . . ) . ) Sylvain Hallé 25
  97. 97. Non-branching LTL Follows three conditions: No temporal operator 1. ( Ú . ( . . . . ) . ) Sylvain Hallé 25
  98. 98. Non-branching LTL Follows three conditions: No temporal operator 1. ( Ú . ( . . . . ) . ) 2. F ( ... ) Sylvain Hallé 25
  99. 99. Non-branching LTL Follows three conditions: No temporal operator 1. ( Ú . ( . . . . ) . ) 2. F ( ... ) Sylvain Hallé 25
  100. 100. Non-branching LTL Follows three conditions: No temporal operator 1. ( Ú . ( . . . . ) . ) 2. F ( ... ) 3. ( U ( . . . . . ) . ) Sylvain Hallé 25
  101. 101. Non-branching LTL Follows three conditions: No temporal operator 1. ( Ú . ( . . . . ) . ) 2. F ( ... ) 3. ( U ( . . . . . ) . ) Sylvain Hallé 25
  102. 102. Non-branching LTL Follows three conditions: No temporal operator 1. ( Ú . ( . . . . ) . ) 2. F ( ... ) 3. ( U ( . . . . . ) . ) Sylvain Hallé 25
  103. 103. 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
  104. 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!) Non-branching LTL contracts can be efficiently enforced Þ through cooperative runtime monitoring Sylvain Hallé 25
  105. 105. Experimental results Sylvain Hallé 26
  106. 106. Experimental results A Sylvain Hallé 26
  107. 107. Experimental results s, s’, A) g= ( () Sylvain Hallé 26
  108. 108. Experimental results s, s’, A) g= ( () = 5.08 ms Sylvain Hallé 26
  109. 109. Experimental results A+ = 5.08 ms Sylvain Hallé 26
  110. 110. Experimental results A,= m T/F () n s’ s, (= ) = 5.08 ms Sylvain Hallé 26
  111. 111. Experimental results A,= m T/F () n s’ s, (= ) = 0.35 ms = 5.08 ms Sylvain Hallé 26
  112. 112. Experimental results = 0.35 ms = 5.08 ms Server is spared of 90% of the computation Sylvain Hallé 26
  113. 113. Experimental results Complete Server-side monitoring Guarantees None Client-side monitoring 0 Computational 100% savings Sylvain Hallé 27
  114. 114. Experimental results Complete Cooperative Server-side monitoring monitoring Guarantees None Client-side monitoring 0 Computational 100% savings Sylvain Hallé 27
  115. 115. Experimental results Expressiveness Complete Cooperative Server-side monitoring monitoring Guarantees None Client-side monitoring 0 Computational 100% savings Sylvain Hallé 27
  116. 116. Experimental results Expressiveness Complete Cooperative Server-side monitoring monitoring Guarantees Non- branching LTL Client-side None monitoring 0 Computational 100% savings Sylvain Hallé 27
  117. 117. 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
  118. 118. 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
  119. 119. 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
  120. 120. Take-home points Sylvain Hallé 28
  121. 121. Take-home points 1. An interface contract specifies valid sequences of ‘‘messages’’ between a client and a server . Sylvain Hallé 28
  122. 122. 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
  123. 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 .. 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
  124. 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... . 4. ...while preserving the same guarantees as with server-side monitoring Sylvain Hallé 28
  125. 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 . 5. This is a 3D problem: guarantees, computational load and expressiveness can be modulated Sylvain Hallé 28

×