HAL Id: tel-01750356
https://hal.univ-lorraine.fr/tel-01750356
Submitted on 29 Mar 2018HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-entific research documents, whether they are
pub-L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non,
Formal verification of the Pastry protocol
Tianxiang Lu
To cite this version:
AVERTISSEMENT
Ce document est le fruit d'un long travail approuvé par le jury de
soutenance et mis à disposition de l'ensemble de la
communauté universitaire élargie.
Il est soumis à la propriété intellectuelle de l'auteur. Ceci
implique une obligation de citation et de référencement lors de
l’utilisation de ce document.
D'autre part, toute contrefaçon, plagiat, reproduction illicite
encourt une poursuite pénale.
Contact : ddoc-theses-contact@univ-lorraine.fr
LIENS
Code de la Propriété Intellectuelle. articles L 122. 4
Code de la Propriété Intellectuelle. articles L 335.2- L 335.10
http://www.cfcopies.com/V2/leg/leg_droi.php
Formal Verification of the Pastry Protocol
Tianxiang Lu
Dissertation zur Erlangung des Grades
des Doktors der Naturwissenschaften
der Naturwissenschaftlich-Technischen Fakult¨
aten
der Universit¨
at des Saarlandes
Tag des Kolloquiums 27. November 2013
Dekan Univ.-Prof. Dr. Mark Groves
Vorsitzender des Pr¨ufungsausschusses Prof. Dr. Holger Hermanns Berichterstatter Prof. Dr. Dominique M´ery
D´epartement de formation doctorale en informatique ´
Ecole doctorale IAEM Lorraine
V´
erification formelle du protocole Pastry
TH ´ESE
pr´esent´ee et soutenue publiquement le 27 novembre 2013 pour l’obtention du
Doctorat de l’Universit´e Henri Poincar´e – Nancy 1 (sp´ecialit´e informatique)
par Tianxiang Lu Pr´esident du jury:
Dominique M´ery (professeur, Univ. de Lorraine) Rapporteurs:
Philippe Qu´einnec (professeur, ENSEEIHT, Toulouse) Peter H. Schmitt (professeur, KIT, Karlsruhe)
Examinateurs:
Dominique M´ery (professeur, Univ. de Lorraine) Roland Meyer (professeur, TU Kaiserslautern) Achour Most´efaoui (professeur, Univ. de Nantes)
Directeurs:
Stephan Merz (directeur de recherche, Inria Nancy)
Christoph Weidenbach (research leader, Max-Planck-Institut f¨ur Informatik, Saarbr¨ucken)
Abstract
Pastry is a structured P2P algorithm realizing a Distributed Hash Table (DHT ) over an underlying virtual ring of nodes. Hash keys are assigned to the numerically closest node, according to their Ids that both keys and nodes share from the same Id space. Nodes join and leave the ring dynamically and it is desired that a lookup request from arbitrary node for a key is routed to the responsible node for that key which then delivers the message as answer.
Several implementations of Pastry are available and have been applied in practice, but no attempt has so far been made to formally describe the algorithm or to verify its properties. Since Pastry combines rather complex data structures, asynchronous communication, concurrency, resilience to churn, i.e. spontaneous join and departure of nodes, it makes an interesting target for verification.
This thesis formally models and improves Pastry’s core algorithms, such that they provide the correct lookup service in the presence of churn and maintain a local data structures to adapt the dynamic updates of neighborhood.
This thesis focuses on Join protocol of Pastry and formally defines different statuses (from “dead” to “ready”) of a node according to its stage during join. Only “ready” nodes are suppose to have consistent key mapping among each other and are allowed to deliver the answer message. The correctness property is identified by this thesis to be CorrectDelivery, stating that there is always at most one node that can deliver an answer to a lookup request for a key and this node is the numerically closest “ready” node to that key. This property is non-trivial to preserve in the presence of churn.
The specification language TLA+ is used to model different versions of Pastry al-gorithm starting with CastroPastry, followed by HaeberlenPastry, IdealPastry and finally LuPastry. The TLA+ model checker TLC is employed to validate the models and to search for bugs. Validation ensures that the system has at least some useful executions; model analysis helps to discover unexpected corner cases to improve the model. Models are simplified for more efficient checking with TLC and consequently mitigating the state explosion problem.
the current joining node that it is “ready”. LuPastry is proved to be correct w.r.t. CorrectDelivery under the assumption that no nodes leave the network, which cannot be further relaxed due to possible network separation when particular nodes simultaneously leave the network.
The most subtle part of the deductive system verification is the search for an appro-priate inductive invariant which implies the required safety property and is inductively preserved by all possible actions. The search is guided by the construction of the proof, where TLC is used to discover unexpected violations of a hypothetical invariant pos-tulated in an earlier stage. The final proof of LuPastry consists of more than 10,000 proof steps, which are interactively checked in time by using TLAPS launching different back-end automated theorem provers.
This thesis serves also as a case study giving the evidence of possibility and the methodology of how to formally model, to analyze and to manually conduct a formal proof of complex transition system for its safety property. Using LuPastry as template, a more general framework on verification of DHT can be constructed.
Zusammenfassung
Pastry ist ein P2P (peer-to-peer ) Algorithmus, der eine verteilte Hashtabelle (DHT) ¨uber einem als virtuellen Ring strukturierten Netzwerk realisiert. Knoten-Identifikatoren und Hash-Schl¨ussel entstammen derselben Menge, und jeder Knoten verwaltet die Schl¨ussel, die seinem Identifikator am n¨achsten liegen. Knoten k¨onnen sich zur Laufzeit ins Netz einf¨ugen bzw. es verlassen. Dennoch sollen Anfragen nach einem Schl¨ussel von beliebigen Knoten immer zu demjenigen Knoten weitergeleitet werden, der den Schl¨ussel verwaltet und der die Anfrage dann beantwortet.
Pastry wurde mehrfach implementiert und praktisch eingesetzt, aber der Algorith-mus wurde bisher noch nie mathematisch pr¨azise modelliert und auf Korrektheit unter-sucht. Da bei Pastry komplexe Datenstrukturen, asynchrone Kommunikation in einem verteilten Netzwerk und Robustheit gegen churn, d.h. spontanes Einf¨ugen oder Ver-lassen von Knoten zusammenkommen, stellt das Protokoll eine interessante Fallstudie f¨ur formale Verifikationstechniken dar.
In dieser Arbeit werden die Kernalgorithmen von Pastry modelliert, die Anfragen nach Schl¨usseln in Gegenwart von churn behandeln und lokale Datenstrukturen ver-walten, welche die jeweiligen Nachbarschaftsbeziehungen zwischen Knoten zur Laufzeit widerspiegeln.
Diese Dissertation behandelt insbesondere das Join-Protokoll von Pastry zum Ein-f¨ugen neuer Knoten ins Netz, das jedem Knoten seinen Status (von “dead” bis “ready”) zuweist. Knoten mit Status “ready” m¨ussen untereinander konsistente Modelle der Zu-st¨andigkeit f¨ur Schl¨ussel aufweisen und d¨urfen Anfragen nach Schl¨usseln beantworten. Als zentrale Korrektheitseigenschaft wird in dieser Arbeit CorrectDelivery untersucht, die ausdr¨uckt, dass zu jeder Zeit h¨ochstens ein Knoten Anfragen nach einem Schl¨ussel beantworten darf, und dass es sich dabei um den Knoten mit Status “ready” handelt, dessen Identifikator dem Schl¨ussel numerisch am n¨achsten liegt. In Gegenwart von churn ist es nicht einfach diese Eigenschaft sicherzustellen.
Wir benutzen die Spezifikationssprache TLA+, um verschiedene Versionen des Pastry-Protokolls zu modellieren: zun¨achst CastroPastry, gefolgt von HaeberlenPastry und IdealPastry, und schließlich LuPastry. Mit Hilfe des Modelcheckers TLC f¨ur TLA+ werden verschiedene qualitative Eigenschaften untersucht, um die Modelle zu va-lidieren und Fehler zu finden. Daf¨ur werden die Modelle zum Teil vereinfacht, um das Problem der Zustandsexplosion zu mindern und so die Effizienz des Modelchecking zu verbessern.
Theorembeweisers TLAPS f¨ur TLA+gezeigt. Das Protokoll IdealPastry stellt sicher, dass ein “ready” Knoten zu jeder Zeit h¨ochstens einen neuen Knoten ins Netz einf¨ugt, und es nimmt an, dass (1) kein Knoten je das Netz verl¨asst und (2) keine zwei Knoten zwischen benachbarten “ready” Knoten eingef¨ugt werden. Der Algorithmus LuPastry verbessert IdealPastry und beseitigt Annahme (2) von IdealPastry. In dieser Ver-sion nimmt ein “ready” Knoten den neu einzuf¨ugenden Knoten unmittelbar in seine Nachbarschaft auf und akzeptiert dann solange keinen weiteren neu hinzukommenden Knoten, bis der erste Knoten best¨atigt, dass er Status “ready” erreicht hat. LuPastry wird als korrekt bez¨uglich der Eigenschaft CorrectDelivery nachgewiesen, unter der An-nahme, dass keine Knoten das Netz verlassen. Diese Annahme kann im allgemeinen nicht vermieden werden, da der Ring in separate Teilnetze zerfallen k¨onnte, wenn bestimmte Knoten gleichzeitig das Netz verlassen.
Die gr¨oßte Herausforderung bei deduktiven Ans¨atzen zur Systemverifikation ist es, eine geeignete Invariante zu finden, die sowohl die angestrebte Sicherheitseigenschaft impliziert als auch induktiv von allen Systemaktionen erhalten wird. W¨ahrend der Kon-struktion des Korrektheitsbeweises wird TLC benutzt, um unerwartete Gegenbeispiele zu hypothetischen Invarianten zu finden, die zuvor postuliert wurden. Der Beweis des LuPastry-Protokolls besteht aus mehr als 10000 Beweisschritten, die von TLAPS und seinen integrierten automatischen Theorembeweisern verifiziert werden.
Die vorliegende Arbeit dient auch als Fallstudie, welche die M¨oglichkeit der formalen Modellierung, Analyse und Korrektheitsbeweises von komplexen Transitionssystemen aufzeigt und die dabei notwendigen Einzelschritte und -techniken behandelt. LuPastry kann als Vorlage benutzt werden, um einen allgemeineren Rahmen f¨ur die Verifikation von DHT-Protokollen zu schaffen.
R´
esum´
e
Pastry est un algorithme qui r´ealise une table de hachage distribu´ee (THD) sur un r´eseau pair `a pair organis´e en un anneau virtuel de nœuds. Chaque nœud g`ere les informations dont les cl´es sont num´eriquement proches de son propre identifiant, sachant que les espaces d’identifiants de nœuds et de cl´es sont confondus dans ce protocole. Le protocole admet que des nœuds puissent rejoindre ou quitter l’anneau `a tout moment. Il doit n´eanmoins faire suivre toute requˆete pour une cl´e, provenant de n’importe quel nœud, au nœud qui est responsable pour cette cl´e et qui r´epondra par l’information recherch´ee.
Il existe plusieurs impl´ementations de Pastry qui ont ´et´e utilis´ees en pratique. Cependant, il n’y a pas encore eu de travaux qui visent `a d´ecrire formellement l’algorithme ou `a v´erifier son bon fonctionnement. Int´egrant des structures de donn´ees complexes, de la communication asynchrone dans un contexte d’un protocole r´eparti et une robustesse vis-`a-vis du churn, i.e. des nœuds qui rejoignent ou quittent le r´eseau, ce protocole repr´esente un int´erˆet certain pour ˆetre analys´e par des techniques de v´erification formelle. Dans cette th`ese nous mod´elisons les algorithmes au cœur de Pastry et qui r´ealisent le service de recherche d’un nœud responsable d’une cl´e en pr´esence de churn. Ces algorithmes maintiennent en particulier une structure locale de donn´ees pour g´erer les ´evolutions dynamiques de la relation de voisinage.
La th`ese ´etudie en particulier le protocole Join de Pastry qui permet `a un nœud de rejoindre le r´eseau et qui associe un statut (variant entre mort et prˆet ) `a tout nœud. Les nœuds prˆets doivent avoir une vue du voisinage coh´erente entre eux ; ils sont autoris´es `a r´epondre `a des messages de recherche d’informations. La propri´et´e principale de correction qui nous int´eresse ici, appel´ee CorrectDelivery, assure qu’`a tout moment il y a au plus un nœud capable de r´epondre `a une requˆete pour une cl´e, et que ce nœud est le nœud le plus proche num´eriquement `a ladite cl´e. Il n’est pas trivial de maintenir cette propri´et´e en pr´esence de churn.
Le langage de sp´ecification formelle TLA+est utilis´e pour mod´eliser diff´erentes ver-sions du protocole Pastry, en commen¸cant par CastroPastry, suivant par Haeberlen-Pastry, IdealHaeberlen-Pastry, puis LuPastry. Le model checker TLC associ´e `a TLA+ sert pour valider des mod`eles et pour trouver des erreurs, en v´erifiant des propri´et´es qualita-tives. Pour ce faire, nous utilisons parfois des mod`eles simplifi´es pour pallier au probl`eme de l’explosion combinatoire du nombre d’´etats.
rejoindre le r´eseau `a la fois, et il suppose que (1) aucun nœud ne quitte le r´eseau et (2) il n’y a jamais deux nœuds qui rejoignent le r´eseau en mˆeme temps entre deux nœuds prˆets proches l’un de l’autre. Cette derni`ere hypoth`ese du protocole IdealPastry est lev´ee dans sa version am´elior´ee LuPastry. Dans cette version, un nœud prˆet ajoute le nœud d´esirant rejoindre le r´eseau imm´ediatement dans son voisinage et n’accepte d’autre requˆete `a rejoindre le r´eseau que si le premier nœud `a confirm´e qu’il est prˆet . Il est montr´e formellement que LuPastry v´erifie CorrectDelivery sous l’hypoth`ese qu’aucun nœud ne quitte le r´eseau. Cette hypoth`ese ne peut ˆetre relˆach´ee `a cause du risque de perte de connexion du r´eseau dans le cas o`u plusieurs nœuds sp´ecifiques quittent le r´eseau en mˆeme temps.
La tˆache la plus ardue en v´erification d´eductive est de trouver un invariant inductif ad´equat qui `a la fois implique la propri´et´e de sˆuret´e que l’on souhaite d´emontrer et est pr´eserv´e par toute action du protocole. Cette tˆache est guid´ee par la construction de la preuve formelle, et l’utilisation de TLC permet de d´ecouvrir des violations inattendues d’invariants hypoth´etiques postul´es au pr´ealable. La preuve finale de LuPastry consiste en environ 10000 ´etapes de preuve qui sont v´erifi´ees par TLAPS et ses diff´erents outils automatiques de preuve.
Par le biais d’une ´etude de cas cons´equente, cette th`ese met en ´evidence la possibilit´e et ´etudie la m´ethodologie pour la mod´elisation d’un syst`eme de transitions complexe et pour son analyse et v´erification d´eductive formelle en vue d’´etablir une propri´et´e de sˆuret´e. En se servant de LuPastry comme une calque, un cadre plus g´en´eral de v´erification de THD peut ˆetre envisag´e.
摘
摘
摘要
要
要
Pastry 是一个将分布式哈希表（DHT）实现在虚拟环结构上的点对点协议的结构化算 法。在这类算法中，哈希密匙（Hash Key）和网络节点共享一个ID域，而密匙被则被 分配在和它ID距离最近的网络节点上。网络节点可能随时加入或离开，而该协议正确的 预期效果之一就是能够为任意的寻址操作提供正确的路由以便得到正确的答案。 Pastry有很多版本并且已经被广泛应用了，但迄今为止，对其算法及正确寻址等性 质的形式化描述或验证尚未有任何进展。Pastry 综合了复杂的数据结构、异步通讯、并 发性、抗震荡性（震荡, churn, 这里指由节点的动态加入和离开所带来的网络拓扑结构 的改变）等多种性质，因而对它的形式化验证成为了很有科学价值的研究课题。 本博士论文对Pastry的核心算法进行了建模，并改善了协议的设计，最终证明了改 善的模型在网络震荡的环境下能够正确寻址。 论文重点分析了算法中节点的加入协议并定义了节点在加入的流程中从断连 （dead）到准备就绪（ready）的不同状态。仅有准备就绪的节点才能保证一致的 哈希映射，并且只有它们能答复寻找密匙的请求。协议的正确性被形式化的描述 为CorrectDelivery, 即在网络运行的任意时刻，最多有一个节点能够向寻址操作提供结 果，且该点应当是所有完备节点中离密匙最近的节点。在网络震荡频发的状态下，这个 性质是很难维持的。 TLA+是一种规约语言，在本文中用于对不同版本的Pastry算法进行建模，其中包括初始的 CastroPastry, 到后继的 HaeberlenPastry，和 IdealPastry以及
Acknowledgements
The research that has gone into this thesis has been thoroughly enjoyable. This enjoy-ment is largely a result of the interaction that I have had with my colleagues at the Automation of Logics group of Max-Planck-Institute, the MOSEL group in LORIA and VeriDis group in INRIA, as well as the support by my mother and friends, who gave me invaluable mental support when I was suffering from a bad mood stemming from other things in my life.
First and foremost, I thank my two advisors Christoph Weidenbach and Stephan Merz, who accepted me as their co-tutelle doctoral student, for their constant support and for the time and energy they invested in our joint work. The guidance, encourage-ment and precious advice on both the research topic and the encourage-mentality of thinking and working rigorously have silently extended my character from only efficiency and goal oriented to placing a huge value on quality and methodology.
I thank Arnaud Fietzke, Willem Hagemann, Marek Kosta and Patrick Wischnewski for the countless informal discussions about mathematics, logics, philosophy and the lovely but often also annoying “rings of Pastry”. I have always considered such discus-sions as a major source of the joy of scientific work.
I thank the anonymous reviewers of the publications that are incorporated in this thesis. Their comments have helped me considerably in obtaining a fresh view on some problems and in improving both my results and my presentation thereof.
Of even greater help was the feedback from my colleague Noran Azmy, my friend Mathieu Flinders, my English teacher Alexei Kirk and my friend Cheng Li who proofread this thesis in different parts and various stages of its formation.
I also thank Leslie Lamport and Peter Druschel, who gave me encouragement and some guidance on my research as the inventors of TLA+ and Pastry respectively.
I thank Dominique M´ery, Roland Meyer, Achour Most´efaoui, Philippe Qu´einnec and Peter H. Schmitt for joining my thesis committee, as well as for interesting discussions and helpful comments.
Contents
0 R´esum´e ´etendu 1
0.1 Motivation . . . 1
0.2 M´ethodologie . . . 4
0.3 Notre preuve de Pastry . . . 7
0.3.1 D´efis dans la mod´elisation de CastroPastry et de Haeberlen-Pastry . . . 8
0.3.2 Analyse des versions CastroPastry et HaeberlenPastry par model checking . . . 8
0.3.3 Preuve de r´eduction . . . 9
0.3.4 Conception et mod´elisation de IdealPastry . . . 9
0.3.5 Validation de IdealPastry . . . 10
0.3.6 V´erification de IdealPastry . . . 10
0.3.7 Relˆacher les hypoth`eses . . . 11
0.3.8 Conception et mod´elisation de LuPastry . . . 12
0.3.9 Validation de LuPastry . . . 12
0.3.10 V´erification de LuPastry . . . 12
0.4 Contributions de la th`ese . . . 12
0.5 Structure du m´emoire de th`ese . . . 14
1 Introduction 15 1.1 Motivation . . . 15
1.2 Methodology . . . 18
1.3 The Story of Verifying Pastry . . . 20
1.3.1 Challenges of Modeling CastroPastry and HaeberlenPastry 21 1.3.2 Model Checking CastroPastry and HaeberlenPastry . . . . 22
1.3.3 Reduction Proof . . . 22
1.3.4 Design and Modeling IdealPastry . . . 22
1.3.5 Validation of IdealPastry . . . 23
1.3.6 Verification of IdealPastry . . . 23
1.3.7 Relaxing the Assumptions . . . 24
1.3.8 Design and Modeling of LuPastry . . . 25
1.3.9 Validation of LuPastry . . . 25
1.3.10 Verification of LuPastry . . . 25
1.4 Contributions of the Thesis . . . 25
Contents
2 Foundations 29
2.1 Peer-to-peer System . . . 29
2.1.1 History, Concept and Definition . . . 30
2.1.2 Classification . . . 31
2.1.3 Structured Decentralized System and DHT . . . 32
2.2 Formal Verification . . . 34
2.2.1 Specification, Validation and Verification . . . 34
2.2.2 Model Checking and Theorem Proving . . . 36
2.3 TLA+ Specification Language . . . 42
2.3.1 Constant Operators . . . 42
2.3.2 Modules . . . 44
2.3.3 Other TLA+ Syntax . . . 46
2.3.4 Transition System . . . 46
2.3.5 Property, Inductive Invariant and Proof . . . 49
2.3.6 Basics of the TLA+ Proof Language . . . 50
3 Pastry Protocol 53 3.1 Algorithms of Pastry . . . 53
3.1.1 Basic Idea of Pastry . . . 53
3.1.2 Notation . . . 57
3.1.3 Pseudocode of CastroPastry . . . 58
3.2 The Join Protocol of Pastry . . . 64
3.2.1 Concurrent Join Problem and CastroPastry . . . 65
3.2.2 Lease-Granting Protocol and HaeberlenPastry . . . 67
3.2.3 Related Work on Pastry . . . 69
3.2.4 Enhancements of the Protocol in IdealPastry and LuPastry . . 70
3.3 The Verified Pastry Join Protocol LuPastry . . . 75
3.3.1 Introduction with Flow Chart and Running Example . . . 76
3.3.2 Statuses of a Node . . . 80
3.3.3 Pseudocode of LuPastry . . . 81
3.3.4 Verification of LuPastry . . . 89
3.4 Assumptions . . . 91
3.5 Summary . . . 92
4 Detailed Formal Model of Pastry 93 4.1 Static Model . . . 93 4.1.1 Ring Operation . . . 93 4.1.2 Leafset . . . 94 4.1.3 Routing Table . . . 96 4.1.4 Messages . . . 98 4.2 Dynamic Model . . . 99
4.2.1 Lookup and Join . . . 101
4.2.2 Routing Actions . . . 102
4.2.3 Actions for Join Protocol . . . 105
Contents
4.2.4 Request and Grant Leases . . . 108
4.2.5 Statuses . . . 111
4.3 The Correctness Properties . . . 111
4.3.1 Type Correctness . . . 111
4.3.2 Safety Property . . . 112
5 Model Checking with TLC 115 5.1 Introduction . . . 115
5.2 Model Analysis on Pastry Properties . . . 117
5.2.1 Analysis of CorrectDelivery on CastroPastry . . . 117
5.2.2 Analysis of NeighborProp on HaeberlenPastry . . . 120
5.2.3 Analysis of Invariants of Final Model of Pastry . . . 123
5.3 Validation . . . 124
5.3.1 Successful Join and Deliver . . . 125
5.3.2 Successful Concurrent Join of Nodes . . . 125
5.3.3 Summary of Model Checking Results . . . 127
5.4 Experiences and Best Practices . . . 128
6 Formal Proof of the Property CorrectDelivery 131 6.1 Reducing CorrectDelivery to NeighborProp . . . 132
6.2 Towards an Inductive Proof of NeighborProp . . . 135
6.2.1 Inductive Proof of Invariant HalfNeighbor . . . 136
6.2.2 Towards an Inductive Proof of Invariant NeighborClosest . . . 139
6.3 A First Inductive Proof of NeighborClosest with Strong Assumptions . . . 143
6.3.1 Implementation of the Assumptions . . . 143
6.3.2 Invariants . . . 144
6.3.3 Proof Sketch of CompleteLeafSet as an Example . . . 148
6.4 Relaxing the Assumptions . . . 150
6.4.1 The Problem of Allowing Departure of Nodes . . . 151
6.4.2 The Approach of Allowing Concurrent Join . . . 152
6.4.3 The Meaning of Allowing Message Loss . . . 154
6.4.4 Modification of the Proof and Invariants . . . 154
6.5 Final Invariants and the Proof . . . 155
6.5.1 Invariants . . . 155
6.5.2 Proof Sketch of the Invariant IRN as an Example . . . 166
6.6 The TLA+ Proof . . . 168
7 Related Works 175 7.1 Other P2P Systems . . . 175
7.1.1 Unstructured Decentralized Systems . . . 176
7.1.2 Hybrid (Partly Centralized) P2P Systems . . . 177
7.1.3 Summary of P2P Systems . . . 178
7.2 Formal Analysis of Chord . . . 178
Contents
7.2.2 Previous Formal Approaches Analyzing Chord . . . 180 7.3 Other Formal Methods Applied on Verifying Correctness of Network
Pro-tocol . . . 181
8 Conclusion and Future Work 185
8.1 Answers to the Questions About Pastry . . . 185 8.2 Answers to Questions About Methodology . . . 187 8.3 Future Work . . . 189 Bibliography . . . 191
List of Figures
0.1 L’anneau virtuel de Pastry. . . 3 0.2 M´ethodologie de v´erification en TLA+. . . 6 1.1 Pastry ring. . . 17 1.2 Verification approach using TLA+. . . 20 2.1 Ontology of networks. . . 31 2.2 Framework of formal verification. . . 35 2.3 The model checking process. . . 37 2.4 The interactive theorem proving process. . . 41 2.5 Proof of Cantor’s Theorem in TLA+. . . 51 3.1 Pastry routing example. . . 55 3.2 Overview of the join protocol of CastroPastry. . . 56 3.3 The ring configuration for the counterexample. . . 66 3.4 Counterexample leading to a violation of CorrectDelivery. . . 66 3.5 Extending the join protocol by lease granting. . . 67 3.6 Node departure handling. . . 69 3.7 The ignored “ok” node. . . 72 3.8 Rejoin counterexample. . . 73 3.9 Separation of the network due to simultaneous departures of nodes. . . 74 3.10 Concurrent join with 5 nodes. . . 75 3.11 Flow chart of complete join process of LuPastry. . . 77 3.12 Join example: upgrades of the status. . . 78 5.1 Screen shot of the TLA+ Toolbox running model checker TLC. . . 115 5.2 Violation trace of concurrent join in CastroPastry. . . 119 5.3 Violation trace of departure and rejoin of nodes in HaeberlenPastry
(part 1). . . 121 5.4 Violation trace of departure and rejoin of nodes in HaeberlenPastry
List of Figures
6.5 Hypothetical violation of CompleteLeafSet by its inductive proof. . . 149 6.6 Separation of the network due to concurrent departures of nodes. . . 151 6.7 Concurrent join with 5 nodes. . . 153 6.8 Hypothetical violation of IRN by its inductive proof. . . 172 6.9 TLA+ codes of the inductive proof of invariants. . . 173 7.1 Different topologies of distributed systems. . . 175
0 R´
esum´
e ´
etendu
Pastry (Rowstron and Druschel (2001), Castro et al. (2004), Haeberlen et al. (2005)) est un algorithme pair `a pair (P2P ) qui r´ealise une table de hachage distribu´ee (DHT Heller-stein (2003)) sur le support d’un r´eseau de recouvrement structur´e en un anneau virtuel de nœuds. Plusieurs impl´ementations de Pastry existent et ont ´et´e utilis´ees en pratique mais `a notre connaissance aucune tentative de description formelle de l’algorithme en vue d’une v´erification de ses propri´et´es n’a jamais ´et´e entreprise. Puisque Pastry est une r´ealisation typique d’une DHT int´egrant des structures de donn´ees assez complexes, de la communication asynchrone, du parall´elisme et qui est suppos´ee r´esister au churn, c’est `a dire `a l’arriv´ee et au d´epart concurrents de nœuds, cet algorithme pr´esente un int´erˆet certain pour la v´erification formelle.
Cette th`ese mod´elise les algorithmes au cœur de Pastry qui fournissent un service de recherche de nœuds en pr´esence de churn et maintiennent une structure de donn´ees locale pour tenir `a jour l’information sur le voisinage de chaque nœud. Dans ce qui suit nous commen¸cons par motiver nos int´erˆets de recherche, puis nous concr´etisons les objectifs de ce travail, et nous expliquons comment ces objectifs sont atteints. Nous terminons par un aper¸cu de ce m´emoire qui servira de guide pour le lire.
0.1 Motivation
La disruption d’un service logiciel tel que Skype (Microsoft (2013)) peut perturber notre vie quotidienne lorsqu’elle rend impossibles les appels des utilisateurs ou inter-rompt brusquement ces appels au milieu d’une conversation. Skype est tr`es connu et utilis´e mondialement par des milliards d’utilisateurs pour passer des appels t´el´ephoniques `
a travers Internet. Le jeudi 16 aoˆut 2007, le r´eseau P2P `a la base de Skype est devenu instable et a souffert d’une perturbation critique malgr´e la capacit´e suppos´ee inn´ee d’un r´eseau P2P `a tol´erer de telles perturbations. Arak (2007) affirme que cet ´ev´enement a r´ev´el´e une erreur logicielle concernant l’algorithme d’allocation de ressources du r´eseau qui n’avait jamais ´et´e rencontr´ee auparavant et qui a empˆech´e l’auto-r´eparation du r´eseau `a fonctionner efficacement. Malheureusement le 23 d´ecembre 2010, des mil-lions d’utilisateurs ont `a nouveau ´et´e incapables de passer des appels, `a nouveau `a cause de d´eparts de plusieurs super-nœuds . Existe-t-il de probl`emes fondamentaux dans la conception de tels r´eseaux qui m`enent invariablement `a des arrˆets intempestifs de temps `
a autre? Sinon, y a-t-il une preuve coh´erente de la correction du protocole?
0 R´esum´e ´etendu
permettant de g´erer des milliards d’appels t´el´ephoniques `a l’´echelle mondiale, selon Mi-crosoft (2013). Ainsi, les syst`emes P2P ont gagn´e en popularit´e depuis le d´ebut du 21`eme si`ecle grˆace `a leurs propri´et´es d’auto-organisation et de d´ecentralisation. Notamment, des syst`emes P2P structur´es r´ealisent des tables de hachage distribu´ees (DHT ) qui sont cens´ees fournir
• un routage efficace et fiable;
• une maintenance de la structure distribu´ee et `a faible coˆut;
• et une robustesse `a des arriv´ees et d´eparts simultan´es de nœuds du r´eseau. C’est pourquoi les DHT servent souvent de base pour des syst`emes r´epartis de grande ´echelle comme Dynamo (DeCandia et al. (2007)), une plate-forme de stockage commune `a diff´erents services au sein d’Amazon. Il est probable que Skype utilise une DHT pour que les pairs puissent trouver l’un l’autre correctement et efficacement.
La correction d’une DHT repose en grande partie sur l’algorithme qui la r´ealise. Le protocole Pastry est l’une des r´ealisations de DHT ayant trouv´e une large utilisation.1 Il r´ealise une DHT en affectant des clefs d’objets (par exemple des identifiants de donn´ees) `
a des nœuds du r´eseau de recouvrement (par exemple des ordinateurs connect´es `a In-ternet) et fournit la primitive lookup pour transmettre une requˆete au nœud qui g`ere la clef correspondante.
Questions autour de Pastry
Puisque Pastry r´ealise une DHT il est int´eressant et crucial de comprendre les m´ecanismes fondamentaux de Pastry et d’analyser et de d´emontrer ses propri´et´es de correction. L’article Castro et al. (2004) introduit Pastry par du pseudo-code au niveau des mes-sages ´echang´es. En partant de cet article nous allons ´etudier les questions suivantes autour de Pastry:
• Comment fonctionne Pastry? En particulier, comment ce protocole r´ealise-t-il une DHT ?
• Que veut dire pr´ecis´ement d’assurer un routage fiable ? Est-ce que Pastry garantit la fiabilit´e du routage? Comment et `a quel degr´e? Existe-t-il une er-reur fondamentale de conception dans Pastry, et particuli`erement dans la version pr´esent´ee dans Castro et al. (2004), quant aux propri´et´es de correction, telles que le routage fiable? Si oui, comment ce probl`eme peut-il survenir? Si non, y a-t-il une preuve formelle de la correction du protocole?
• Existe-t-il d’autres propri´et´es d’int´erˆet d’une telle r´ealisation d’une DHT ? Ces propri´et´es sont-elles reli´ees les unes aux autres?
1
Dans cette th`ese nous distinguons diff´erents niveaux d’abstraction. Nous employons le mot r´ealisation pour d´esigner le raffinement du concept de DHT `a un algorithme concret comme Pastry. Le mot impl´ementation d´esigne diff´erentes versions d’un algorithme. Les deux mots font r´ef´erence `a
diff´erents niveaux de d´etail dans la conception, et nous n’utilisons aucun de ces mots pour d´esigner un logiciel ex´ecutable.
0.1 Motivation
Figure 0.1: L’anneau virtuel de Pastry.
Les principes du fonctionnement de Pastry
Dans Pastry, les nœuds du r´eseau de recouvrement sont num´erot´es par des identifiants tir´es dans l’intervalle des entiers [0, 2M − 1] pour un certain M . L’espace des identifiants est consid´er´e comme un anneau, comme c’est montr´e `a la figure 0.1. En particulier, le nœud 2M − 1 est voisin du nœud 0.
Les mˆemes identifiants servent aussi de clefs d’objets, de mani`ere `a ce qu’un nœud g`ere les clefs qui sont num´eriquement proches de son identifiant. Il d´etient ainsi la copie principale de chaque entr´ee dans la DHT associ´ee `a l’une de ces clefs. La responsabilit´e des clefs est r´epartie uniform´ement selon la distance entre deux nœuds voisins. Si un nœud est responsable d’une clef nous disons qu’il g`ere ou qu’il couvre cette clef, comme c’est illustr´e `a la figure 0.1.
Les deux principaux sous-protocoles de Pastry s’appellent join et lookup. Le proto-cole join permet `a un nœud avec un identifiant non encore utilis´e de rejoindre l’anneau. Le protocole lookup retrouve l’information associ´ee par la DHT `a une clef donn´ee (ou, de mani`ere ´equivalente, le nœud qui couvre cette clef). Le protocole Pastry est cens´e assurer une association coh´erente entre les clefs et les nœuds et fournir un service correct de lookup mˆeme en pr´esence de churn, c’est `a dire l’arriv´ee et le d´epart spontan´es de nœuds.
Comme les voisins d’un nœud dans Pastry peuvent changer dynamiquement `a cause de churn, chaque nœud maintient dans son ´etat local une structure appel´ee leaf set qui repr´esente son voisinage imm´ediat. Comme c’est illustr´e `a la figure 0.1, un leaf set est constitu´e de deux ensembles de taille ´egale indiquant les voisins `a gauche et `a droite. La taille de ces ensembles est un param`etre de l’algorithme. Le contenu des leaf sets est mis `
0 R´esum´e ´etendu
par un protocole de maintenance. Pour assurer un routage efficace, chaque nœud de Pastry maintient aussi une table de routage qui contient des nœuds plus distants. Dans l’exemple de la figure 0.1, le nœud a re¸coit une requˆete lookup pour la clef k . Cette clef n’est pas couverte par a, aussi elle r´eside en dehors de l’intervalle entre les nœuds les plus distants contenus dans son leaf set. La table de routage du nœud a indique le nœud b comme celui dont l’identifiant partage le plus long pr´efixe commun avec la clef demand´ee, et a transmet la requˆete `a ce nœud. Le nœud b continue ce processus et enfin, la requˆete arrive au nœud c qui est le nœud le plus proche `a la clef k et qui couvre donc cette clef. On dit que le nœud c d´elivre la requˆete pour la clef k .
Les r´esultats de cette th`ese
Dans cette th`ese nous distinguons les nœuds selon leur statut qui peut ˆetre dead , waiting , ok et ready et qui indique son degr´e d’int´egration dans l’anneau et sa capacit´e `a r´epondre `a des requˆetes. Seuls les nœuds dont le statut est ready sont suppos´es avoir une vision coh´erente de la couverture des clefs dans leur voisinage et peuvent d´elivrer des requˆetes. Nous d´efinissons le concept de routage fiable par la formule CorrectDelivery qui exige qu’`a tout moment il existe au plus un nœud qui peut d´elivrer une requˆete pour une clef donn´ee, et qu’il s’agit du nœud ready le plus proche num´eriquement de la clef. Il n’est pas trivial de garantir cette propri´et´e en pr´esence de churn. Nous utilisons une m´ethode formelle de preuve pour d´emontrer que la propri´et´e CorrectDelivery est v´erifi´ee en pr´esence d’arriv´ees concurrentes de nouveaux nœuds dans n’importe quelle r´egion de l’anneau, sous l’hypoth`ese qu’aucun nœud ne quitte le r´eseau. Nous montrons qu’il est difficile de relˆacher cette hypoth`ese forte car les d´eparts de certains nœuds peuvent induire une s´eparation permanente du r´eseau.
0.2 M´
ethodologie
Les m´ethodes formelles (Clarke and Wing (1996)) fournissent des techniques syst´ematiques et rigoureuses pour sp´ecifier et v´erifier la conception d’un syst`eme logiciel. Fond´ees sur des principes math´ematiques et logiques, elles peuvent d´eceler des probl`emes d’inconsistance, d’ambig¨uit´e ou d’incompl´etude au sein des sp´ecifications d’un syst`eme. Avec l’av`enement des techniques de v´erification algorithmique (model checking ) et de preuve automatique qui augmentent tr`es significativement le degr´e d’automatisation d’une preuve interac-tive, coupl´ees `a la haute expressivit´e de ces m´ethodes, il est d´esormais temps d’´etudier s’il devient possible d’analyser par des m´ethodes formelles un protocole r´eparti d’une complexit´e r´ealiste, tel que Pastry.
Questions autour de la m´ethodologie
Au-del`a d’une meilleure compr´ehension de Pastry, cette th`ese illustre comment les m´ethodes formelles peuvent ˆetre utilis´ees pour l’analyse de syst`emes r´epartis, au-del`a de la seule d´ecouverte d’erreurs dans des syst`emes jouets et abstraits:
0.2 M´ethodologie • Comment mod´eliser formellement Pastry? Quel est le niveau d’abstraction ad´equat
pour la mod´elisation?
• Comment exprimer formellement les propri´et´es de correction de Pastry? Est-il possible, et comment, de d´emontrer leur invariance tout en consid´erant les d´etails du protocole, tels que la communication asynchrone et des structures de donn´ees complexes?
• `A quel degr´e la v´erification formelle d’un tel syst`eme peut-elle ˆetre automatis´ee? Pourquoi TLA+
Cette th`ese utilise la m´ethode TLA+ de Lamport (2002) pour d´ecrire et v´erifier la correction du routage et du traitement des requˆetes dans Pastry. En effet, TLA+fournit un cadre logique uniforme pour la sp´ecification, le model checking et la preuve formelle. La structure du langage TLA+ est tres appropri´ee `a la v´erification de protocoles car le concept d’actions correspond `a la d´efinition de protocoles par des r`egles en r´eponse aux messages re¸cus.
TLA+ est un langage de sp´ecification de haut niveau d’abstraction qui a ´et´e utilis´e pour sp´ecifier et analyser la correction de plusieurs protocoles mat´eriels et qui est large-ment utilis´e pour la sp´ecification et la v´erification d’algorithmes concurrents et distribu´es. Les notions de TLA+ n´ecessaires `a la compr´ehension de cette th`ese seront introduites en plus de d´etail dans le chapitre 2.
TLC, introduit dans Yu et al. (1999), est l’outil de v´erification algorithmique associ´e `
a TLA+. Il est fond´e sur des techniques d’exploration explicite de l’espace d’´etats et permet de d´etecter des erreurs dans des mod`eles TLA+. TLC est particuli`erement utile pour la validation d’instances de petite taille de mod`eles TLA+. Il permet de comprendre dans le d´etail le comportement d’un syst`eme d´ecrit par une sp´ecification TLA+ et de d´ecouvrir des propri´et´es et, plus souvent, des non-propri´et´es, comme cela sera expliqu´e dans le chapitre 5. TLC peut ˆetre ex´ecut´e soit `a partir d’une ligne de commande sur un serveur, soit `a l’aide d’une interface graphique conviviale appel´ee Toolbox qui int`egre un ´editeur pour le langage de mod´elisation TLA+, ainsi que les outils d’analyse associ´es tels que TLC. Une premi`ere version de la Toolbox TLA+, implant´ee sous Eclipse2, est publiquement disponible depuis f´evrier 2010 et r´eguli`erement mise `a jour depuis.
TLA+ comporte un langage d´eclaratif de preuve dont la syntaxe et la s´emantique sont d´ecrites en d´etail dans Chaudhuri et al. (2010) et Cousineau et al. (2012). Un exemple d’une preuve en TLA+ apparaˆıt `a la fin du chapitre 6, illustrant sa syntaxe et son utilisation pour la preuve de Pastry.
TLAPS (voir Lamport (2012a)) est une plate-forme interactive de preuve qui per-met la v´erification d´eductive de propri´et´es de mod`eles TLA+. Elle comporte un ges-tionnaire de preuves (proof manager, PM) qui interpr`ete le langage de preuve et d´eroule les d´efinitions d’op´erateurs afin de g´en´erer les obligations de preuve correspondantes aux diff´erentes ´etapes d’une preuve TLA+. Le PM fait ensuite appel `a des outils de
0 R´esum´e ´etendu
Description informelle Mod´elisation en TLA+ Mod`ele
statique Propri´et´es
Mod`ele dynamique Contre-exemples Model Checking par TLC Mod`ele valid´e pour de petites instances Preuve d´eductive par TLAPS Relaxations d’hypoth`eses Preuve
Figure 0.2: M´ethodologie de v´erification en TLA+.
v´erification automatis´es pour essayer de d´emontrer les obligations de preuve g´en´er´ees. Les outils de preuve fournis avec la version initiale de TLAPS ont ´et´e Zenon, un prou-veur fond´e sur la m´ethode des tableaux (Bonichon et al. (2007)) et Isabelle/TLA+, un encodage de TLA+ en Isabelle/Pure (Wenzel et al. (2008)). Depuis 2012, il existe ´egalement une interface avec les outils de r´esolution SMT (satisfiabilit´e modulo th´eories) `
a partir de TLAPS, tels que Yices (Dutertre and De Moura (2006)), CVC3 (Barrett and Tinelli (2007)) et Z3 (De Moura and Bjørner (2008)).
Comme nous l’avons dit plus haut, le langage TLA+ est bien adapt´e `a la v´erification de protocoles parce que son concept d’actions correspond `a la d´efinition de protocoles par des r`egles en r´eponse aux messages re¸cus par un nœud du r´eseau. Aussi, il est ais´e de comprendre le langage qui repose sur des concepts ´el´ementaires et classiques math´ematiques et logiques. L’int´egration de TLC et TLAPS dans la Toolbox rend conviviale l’utilisation des outils de model checking et de preuve sur un mˆeme mod`ele. C’est pourquoi nous utilisons TLA+ dans cette th`ese pour sp´ecifier un protocole r´eparti ainsi que pour analyser ses propri´et´es et pour v´erifier sa correction.
M´ethodologie g´en´erale de v´erification en TLA+
La figure 0.2 illustre la m´ethodologie de v´erification en TLA+ qui comporte les ´etapes de mod´elisation, de model checking et de preuve d´eductive.
Partant d’une description informelle d’un syst`eme r´eparti, la premi`ere ´etape est de
0.3 Notre preuve de Pastry encoder les propri´et´es, les structures de donn´ees, le comportement et l’environnement du syst`eme par un mod`ele TLA+. Dans cette th`ese nous distinguons diff´erentes formes de mod`eles TLA+: les propri´et´es expriment des exigences de haut niveau par des for-mules logiques, le mod`ele statique d´efinit les structures de donn´ees par des primitives de TLA+ comme les tableaux, les listes, les fonctions et les enregistrements, et le mod`ele dynamique sp´ecifie le comportement du syst`eme par des actions de TLA+. Dans ce qui suit, l’environnement du syst`eme correspondra `a des hypoth`eses qui sont formul´ees et impos´ees par des pr´e-conditions d’actions dans le mod`ele.
L’´etape suivante est l’utilisation it´erative de TLC pour d´eboguer et valider le mod`ele construit. La limitation principale est ici le probl`eme bien connu de l’explosion com-binatoire de l’espace d’´etats, aussi est-il n´ecessaire de restreindre le mod`ele `a un petit nombre d’instances. Des contre-exemples fournis par TLC servent `a analyser et corriger le mod`ele. Une fois les propri´et´es valid´ees par TLC (ou au moins que TLC ne d´ecouvre plus de contre-exemples apr`es l’avoir laiss´e tourner pendant suffisamment longtemps), le mod`ele pourra ˆetre v´erifi´e en toute g´en´eralit´e par des preuves TLA+.
La v´erification d´eductive de protocoles distribu´es repose typiquement sur une preuve inductive qui n´ecessite la d´ecouverte et la formulation d’invariants. TLC est l`a encore utile pour valider la formulation d’invariants hypoth´etiques avant d’entamer leur preuve. En g´en´eral, l’invariant doit ˆetre renforc´e lors de la construction de la preuve. TLAPS est utilis´e pour r´ediger et certifier la preuve formelle, en la d´ecomposant en des morceaux suffisamment petits pour que les outils de preuve automatiques arrivent `a les v´erifier. Le r´esultat final est une preuve TLA+ dont chaque ´etape est v´erifi´ee automatiquement par TLAPS.
0.3 Notre preuve de Pastry
Cette section donne un r´esum´e g´en´eral des d´efis rencontr´es et des le¸cons que nous avons retenues pendant la pr´eparation de cette th`ese.
L’´etude de Pastry commence par la mod´elisation des aspects statiques et dynamiques de l’algorithme. Le mod`ele formel CastroPastry de Pastry, bas´e sur Castro et al. (2004), est analys´e par le model checker TLC. Des am´eliorations successives donnent le mod`ele formel HaeberlenPastry, int´egrant des id´ees d´ecrites dans Haeberlen et al. (2005). Enfin, TLAPS est utilis´e pour d´emontrer que Pastry v´erifie bien la propri´et´e CorrectDelivery pour un nombre quelconque d’instances. Le protocole Pastry est d’abord v´erifi´e dans sa version IdealPastry et sous deux hypoth`ese fortes qui sont (1) qu’il n’y a pas deux nœuds qui rejoignent le r´eseau dans une mˆeme r´egion de couverture autour d’un nœud ready et de ses voisins imm´ediats et (2) qu’aucun nœud ne quitte le r´eseau. La premi`ere hypoth`ese sera relˆach´ee dans la version LuPastry qui est aussi v´erifi´ee par TLAPS sous l’hypoth`ese qu’aucun nœud ne quitte le r´eseau.
0 R´esum´e ´etendu
0.3.1 D´efis dans la mod´elisation de CastroPastry et de HaeberlenPastry
Le premier probl`eme a ´et´e de d´eterminer un niveau d’abstraction appropri´e dans la mod´elisation formelle de l’algorithme. Par exemple, des bornes temporels servent `a lim-iter les temps d’attente de r´eponse `a un message envoy´e. Pass´e ces d´elais, un nœud peut supposer que le message a ´et´e perdu et soit l’envoyer `a nouveau, soit suspecter que le destinataire a quitt´e le r´eseau. Afin de simplifier le mod`ele formel et d’am´eliorer la tractabilit´e du probl`eme de model checking, les actions d´ependantes du temps r´eel de Pastry sont repr´esent´ees en TLA+ comme si elles apparaissaient de mani`ere non-d´eterministe. Par contre, les d´etails d’envoi et de r´eception de messages et le contenu de ces messages ne peuvent ˆetre abstraits, et le mod`ele refl`ete une communication asyn-chrone dans laquelle il n’y a pas de garantie quant `a la pr´eservation de l’ordre des messages envoy´es.
Le second d´efi a ´et´e de compl´eter des d´etails qui n’apparaissent pas clairement dans la description de l’algorithme Pastry, `a l’aide de contre-exemples fournis par le model checker. Par exemple, il n’est pas dit clairement ce que veut dire qu’une structure locale est compl`ete , une condition n´ecessaire pour qu’un nœud puisse passer d’une ´etape `a l’autre dans le protocole join.
Des hypoth`eses explicites doivent ˆetre prises quant au traitement de cas particuliers, et pour cela nous avons parfois examin´e le code source de FreePastry (2009). Ainsi, il peut y avoir un recouvrement des deux leaf set d’un nœud, par exemple dans le cas d’un unique nœud actif dans l’anneau. Aucune description particuli`ere de ce cas n’est donn´ee dans Castro et al. (2004). Nous fournissons une d´efinition pr´ecise de la compl´etude des leaf set, et nous d´ecrivons pr´ecis´ement comment sont trait´es les cas particuliers dans notre mod`ele. Parfois nous avons ´etabli plusieurs mod`eles qui d´ecrivent diff´erentes alternatives, fond´ees sur des hypoth`eses qui nous paraissaient plausibles.
Un d´efi dans un autre registre a ´et´e de formuler les propri´et´es de correction car elles ne sont pas indiqu´ees clairement dans Castro et al. (2004). Le concept d’un nœud ayant le statut ready est introduit afin de distinguer les nœuds qui ont une vue locale coh´erente de la DHT . Seuls ces nœuds peuvent d´elivrer des requˆetes lookup. La propri´et´e principale CorrectDelivery dit qu’une requˆete lookup pour une certaine clef ne peut ˆetre d´elivr´ee que par le nœud ready qui est num´eriquement le plus proche de la clef. Cette propri´et´e est exprim´ee par une formule temporelle en TLA+.
Le model checker TLC a ´et´e utilis´e pour valider et am´eliorer le mod`ele Castro-Pastry. Le mod`ele formel avec quelques r´esultats du model checking a ´et´e publi´e dans Lu et al. (2010). Le pseudo-code de la version CastroPastry qui contient tous les d´etails sera donn´e `a la section 3.1.3, et le mod`ele formel est disponible en ligne `a VeriDis (2013).
0.3.2 Analyse des versions CastroPastry et HaeberlenPastry par model checking
Apr`es avoir mod´elis´e Pastry en TLA+ dans le mod`ele CastroPastry sur la base de Castro et al. (2004), le model checker TLC a ´et´e utilis´e pour analyser les propri´et´es de
0.3 Notre preuve de Pastry ce mod`ele et pour ainsi affiner la compr´ehension de Pastry.
Un contre-exemple `a la propri´et´e CorrectDelivery est d´ecouvert par TLC pour CastroPastry. Il montre comment deux nœuds peuvent rejoindre le r´eseau en par-all`ele entre deux nœuds ready sans avoir pris connaissance l’un de l’autre `a la fin du protocole join. Ce contre-exemple sera d´ecrit en d´etail `a la section 3.2.1.
Il est ais´e de voir que ce probl`eme est fondamentalement dˆu `a la communication asyn-chrone, propri´et´e caract´eristique de syst`emes distribu´es qui a pour effet de reordonner les messages par lesquels les nœuds ´echangent leurs ´etats locaux. Une solution inspir´ee par Haeberlen et al. (2005) et FreePastry (2009) est d’´etendre le protocole join par un sous-protocole suppl´ementaire qui inclut une confirmation de la coh´erences des vues du voisinage par un processus appel´e ´echange de bail , et ce protocole est formalis´e par le mod`ele HaeberlenPastry, expliqu´e en d´etail `a la section 3.2.2. Ce mod`ele formel est ´egalement disponible en ligne `a VeriDis (2013).
De mani`ere analogue `a la d´ecouverte du contre-exemple pour CastroPastry, plusieurs autres contre-exemples sont d´ecouverts automatiquement par le biais des anal-yses par model checking des versions CastroPastry et HaeberlenPastry, et ils conduisent `a des am´eliorations des mod`eles de Pastry. Cette analyse du protocole join et les am´eliorations y apport´ees sont d´ecrites en d´etail `a la section 3.2. Plus de d´etails sur l’analyse par model checking apparaissent au chapitre 5.
0.3.3 Preuve de r´eduction
Apr`es que TLC ne trouve plus de contre-exemples lors de l’analyse d’une instance de HaeberlenPastry comportant quatre nœuds au bout de 24h d’ex´ecution, nous sommes assez confiants dans le mod`ele pour entamer une preuve d´eductive de correction pour un nombre quelconque de nœuds. Cette preuve est conduite `a l’aide du langage de preuve de TLA+, mise en œuvre dans la plate-forme TLAPS pour le d´eveloppement et la v´erification de preuves en TLA+. Un premier r´esultat publi´e dans ? r´eduit la propri´et´e globale de correction de Pastry appel´ee CorrectDelivery `a des invariants sur les structures de donn´ees utilis´ees dans le protocole (voir la section 6.1).
0.3.4 Conception et mod´elisation de IdealPastry
Une analyse plus pouss´ee du contre-exemple trouv´e pour la version CastroPastry conduit `a la d´ecouverte de la raison fondamentale de la violation de la propri´et´e Cor-rectDelivery: en effet, le protocole choisit d’envoyer l’´etat du destinataire apr`es sa mise `
a jour plutˆot que celui avant. Alors que le nœud destinataire du message am´eliore sa vision de l’´etat global par l’information contenue dans le message, cette mise `a jour n’apporte aucune information suppl´ementaire `a l’´emetteur du message. Elle peut cepen-dant d´etruire des informations utiles qui se trouvaient dans l’´etat local du destinataire avant la mise `a jour. Ainsi, une solution `a ce probl`eme est de renvoyer l’´etat ant´erieur du nœud en r´eponse au message re¸cu, et nous allons introduire cette modification au protocole `a la section 3.2.4.
0 R´esum´e ´etendu
HaeberlenPastry est n´ecessaire pour pr´evenir au probl`eme de nœuds ok qui pour-raient ˆetre oubli´es: un nœud pourrait r´eussir `a ´echanger des messages probe `a l’aide de nœuds qui rejoignent l’anneau mais sans ˆetre ajout´e au voisinage du nœud ready le plus proche. Davantage de d´etails seront donn´es `a la section 3.2.4.
Int´egrant toutes les am´eliorations trouv´ees pendant la phase de model checking, nous obtenons le mod`ele IdealPastry en TLA+. Ce mod`ele est disponible en ligne `
a VeriDis (2013).
Le mod`ele IdealPastry suppose qu’il n’y a jamais deux nœuds qui cherchent `a rejoindre l’anneau entre deux mˆemes nœuds ready proches l’un de l’autre. Cette hypoth`ese est r´ealis´ee en empˆechant un nœud `a traiter d’autres requˆetes join d`es lors qu’il r´epond `a une requˆete join d’un nœud proche. Au-del`a de ce nœud, ses voisins doivent ´egalement ˆetre empˆech´es `a traiter des requˆetes join. Puisque le fait de bloquer d’autres nœuds n´ecessite une communication entre les nœuds, la version IdealPastry ne d´ecrit qu’un protocole abstrait et id´ealis´e qui n´ecessite une r´ealisation algorithmique pour sa mise en œuvre.
0.3.5 Validation de IdealPastry
Le mod`ele formel IdealPastry est valid´e `a l’aide de TLC, et le r´esultat peut ˆetre trouv´e en ligne au mˆeme endroit que le mod`ele `a VeriDis (2013).
0.3.6 V´erification de IdealPastry
Le mod`ele IdealPastry est v´erifi´e par une preuve inductive d’invariants, sous la dou-ble hypoth`ese qu’aucun nœud ne quitte le r´eseau et qu’il n’y ait pas deux nœuds qui cherchent `a rejoindre l’anneau dans la r´egion couverte par un nœud ready et ses voisins imm´ediats.
La partie la plus subtile de cette preuve d´eductive est la d´efinition d’un invariant in-ductif appropri´e qui implique la propri´et´e qui nous int´eresse et qui est pr´eserv´e par toutes les actions du protocole. Cette d´efinition est guid´ee par construction de la preuve, lors de laquelle nous utilisons TLC pour d´ecouvrir tˆot des violations inattendues d’invariants hypoth´etiques. Plus pr´ecis´ement, les d´efis suivants sont confront´es pendant la preuve d’invariants inductifs.
D’abord, il faut s´eparer consciencieusement les lemmes statiques sur les struc-tures de donn´ees des invariants sur le comportement dynamique du syst`eme. Puisque le mod`ele qui repr´esente Pastry contient plusieurs structures de donn´ees complexes telles que l’anneau, les leaf set et la table de routage avec des op´erations complexes, les propri´et´es de ces structures de donn´ees et des op´erations associ´ees sont d´emontr´ees s´epar´ement de la preuve inductive, afin que cette derni`ere soit focalis´ee sur l’aspect dy-namique. Dans la syntaxe des formules, cette s´eparation est indiqu´ee par le fait qu’une formule porte sur toute instance arbitraire de la structure de donn´ees ou qu’elle concerne une variable d’´etat pr´ecise qui implante la structure en question dans le protocole. Par exemple, une propri´et´e que nous avons eu `a d´emontrer ´enonce que l’ajout d’un nœud `
a un leaf set appartenant `a un nœud n ne peut que r´eduire la distance entre n et ses
0.3 Notre preuve de Pastry voisins imm´ediats. Bien que cette propri´et´e ´evoque la modification d’un leaf set, elle s’applique `a tout nœud et non seulement `a un nœud particulier dans une certaine phase du protocole. Il s’agit donc d’une propri´et´e statique concernant la structure de donn´ees des leaf set et non d’un invariant. Une autre propri´et´e dit que si le nœud i appartient au leaf set d’un autre nœud j qui n’est pas en train d’aider i `a rejoindre l’anneau, alors le leaf set du nœud i n’est pas vide. Cette propri´et´e est un invariant car la question si le leaf set du nœud i est ou n’est pas vide est une propri´et´e dynamique.
Ensuite, il peut ˆetre difficile de trouver des g´en´eralisations appropri´ees d’invariants qui doivent ˆetre d´emontr´es `a ˆetre pr´eserv´es par toutes les actions du syst`eme de tran-sitions correspondant `a l’algorithme Pastry. Effectivement, l’ensemble des invariants ne peut ˆetre finalis´e qu’en mˆeme temps que les preuves car un nouvel invariant pourra ˆetre d´ecouvert lors de la preuve d’un cas particulier d’un invariant existant. Il est important d’esquisser la preuve enti`ere d’invariance a priori afin d’´eviter d’ˆetre perdu dans les d´etails de formulation. L’attention `a des cas particuliers et la d´ecouverte de contre-exemples sont utiles pour la construction de l’invariant. Il n’est pas toujours possible d’utiliser le model checker: un cas particulier important n’a ´et´e trouv´e qu’`a la main pendant la recherche d’invariants. Ce contre-exemple `a la propri´et´e CorrectDelivery n’apparaˆıt que si plus de cinq nœuds interviennent, dont trois qui rejoignent l’anneau `a des positions sp´ecifiques. Les d´etails seront expliqu´es `a la section 6.4.2.
Troisi`emement, il n’est pas toujours trivial de donner les arguments appropri´es `a la preuve m´ecanique, y compris les appels n´ecessaires `a des lemmes et faits pr´ec´edemment d´emontr´es. Des ´etapes ´evidentes pour l’humain qui applique un raisonnement logique implicite peuvent devenir des ´etapes compliqu´ees de preuve n´ecessitant l’´enum´eration de lemmes triviaux mais n´ecessaires. Parfois l’esquisse manuelle de la preuve comporte effectivement des lacunes importantes qui doivent ˆetre adress´ees. Dans ce cas il faut con-struire une nouvelle esquisse de preuve, n´ecessitant sa reconstruction ou parfois mˆeme une modification de l’invariant. C’est pourquoi le recours `a un outil de preuve automa-tique est une aide cruciale `a la construction et la v´erification de la preuve. Dans d’autres cas, l’outil peut ˆetre incapable de d´emontrer une certaine obligation pourtant valide, et il faut alors d´ecomposer sa preuve en un niveau suppl´ementaire d’interaction.
`
A la fin, une preuve d´eductive compl`ete a ´et´e construite dans le langage de preuve de TLA+. Elle consiste en environ 10000 ´etapes de preuve qui sont toutes v´erifi´ees `a temps par TLAPS en faisant appel `a diff´erents outils de preuve automatis´es. Les d´etails seront expliqu´es `a la section 6.3.
0.3.7 Relˆacher les hypoth`eses
Un contre-exemple `a la propri´et´e CorrectDelivery sur le mod`ele IdealPastry est d´ecouvert `
0 R´esum´e ´etendu
0.3.8 Conception et mod´elisation de LuPastry
L’analyse du probl`eme de requˆetes join concurrentes conduit `a une am´elioration de la conception de Pastry appel´e LuPastry. Dans cette version, un nœud ready ajoute directement le nœud qui cherche `a rejoindre l’anneau d`es la r´eception de la requˆete, et n’accepte aucune nouvelle requˆete join avant d’avoir re¸cu la confirmation que le nouveau nœud est lui-mˆeme devenu ready . Le mod`ele formel de LuPastry est expliqu´e au chapitre 4.
0.3.9 Validation de LuPastry
Le mod`ele LuPastry est valid´e par TLC, et les r´esultats apparaissent au tableau 5.3.
0.3.10 V´erification de LuPastry
Nous d´emontrons que le mod`ele LuPastry v´erifie ´egalement la propri´et´e CorrectDelivery pour peu qu’aucun nœud ne quitte le r´eseau. Les invariants de ce mod`ele sont introduits `
a la section 6.5.
Il n’est pas trivial d’adapter la preuve de IdealPastry `a LuPastry. TLAPS dispose d’une commande pour examiner le statut d’une preuve et de ses sous-preuves, et cette commande indique quelles ´etapes de la preuve sont affect´ees par les modifications du mod`ele. Cependant, de nombreuses ´etapes de preuve ne sont plus valides, et ces ´etapes doivent ˆetre ´etudi´ees attentivement. Les d´etails des modifications apport´ees aux invariants et aux preuves sont indiqu´es `a la section 6.4.4.
Un exemple d’une preuve en TLA+ est donn´e `a la fin du chapitre 6, expliquant la syntaxe et l’usage de TLAPS. La preuve formelle enti`ere est trop longue pour ˆetre incluse dans cette th`ese; elle est disponible en ligne `a VeriDis (2013).
0.4 Contributions de la th`
ese
La contribution principale de cette th`ese est l’analyse et l’am´elioration d’un algorithme r´eel Pastry r´ealisant une DHT . Ainsi, nous illustrons et ´etendons l’usage de m´ethodes formelles pour la v´erification d’algorithmes r´epartis. Cette section r´esume nos contribu-tions qui ont en fait d´ej`a ´et´e mentionn´ees dans les sections pr´ec´edentes.
• L’algorithme Pastry introduit par Castro et al. (2004) est mod´elis´e formellement au niveau des ´echanges de messages par le mod`ele CastroPastry (section 3.1.3). Il s’agit du premier mod`ele formel et complet d’un tel algorithme complexe P2P . Sa version am´elior´ee par Haeberlen et al. (2005) est ´egalement repr´esent´ee dans le mod`ele HaeberlenPastry.
• Une propri´et´e fondamentale de correction de Pastry est d´efinie et repr´esent´ee par la formule CorrectDelivery (section 4.3.2). Elle dit qu’`a tout moment il existe au plus un nœud qui peut d´elivrer une clef, et que c’est le nœud ready le plus proche de la clef.
0.4 Contributions de la th`ese • Le protocole join de Pastry est ´etudi´e en d´etail. Des violations de CorrectDelivery par les mod`eles CastroPastry et HaeberlenPastry sont exhib´ees et analys´ees aux sections 3.2 et 5.2.
• Les mod`eles HaeberlenPastry, IdealPastry et LuPastry introduisent diff´erents statuts de nœuds ( dead , waiting , ok et ready ) refl´etant leurs progres-sions dans le protocole join et leurs capacit´es `a d´elivrer des clefs (section 3.3.2). Les seuls nœuds ready sont suppos´es de disposer d’informations coh´erentes quant `a la couverture de clefs et sont autoris´es `a d´elivrer des requˆetes lookup.
• Le mod`ele IdealPastry r´esume les am´eliorations induites par l’analyse de Castro-Pastry et HaeberlenCastro-Pastry. Nous d´emontrons par une preuve inductive d’invariants qu’il v´erifie la propri´et´e CorrectDelivery, sous les hypoth`eses qu’aucun nœud ne quitte le r´eseau et que deux nœuds ne cherchent jamais `a rejoindre l’anneau dans la r´egion couverte par un nœud ready et ses voisins imm´ediats.
• Une sp´ecification formelle LuPastry de l’algorithme Pastry est con¸cue sur la base de IdealPastry (introduite en pseudo-code `a la section 3.3.3). Son am´elioration r´eside dans le fait qu’un nœud ready ajoute un nœud arrivant dans le r´eseau d`es qu’il traite la requˆete join et n’accepte alors plus de requˆete join jusqu’`a ce qu’il re¸coive la confirmation que le nouveau nœud est devenu ready . Le mod`ele LuPastry est d´emontr´ee correct par rapport `a CorrectDelivery sous l’hypoth`ese qu’aucun nœud ne quitte l’anneau. Les invariants utilis´es dans la preuve sont in-troduits `a la section 6.5. Il n’est pas facile de relˆacher cette hypoth`ese sur le d´epart de nœuds `a cause de contre-exemples qui montrent qu’une s´eparation permanente du r´eseau peut intervenir lorsque plusieurs nœuds partent simultan´ement.
• Le model checker TLC est utilis´e de mani`ere intensive pour d´eboguer et valider les diff´erents mod`eles de Pastry sur des instances impliquant entre trois et cinq nœuds. Des versions simplifi´ees sont con¸cues afin de surmonter le probl`eme de l’explosion combinatoire de l’espace d’´etats. Nous r´esumons nos exp´eriences et nos propositions quant `a l’utilisation de TLC au chapitre 5 qui donne ´egalement les d´etails de nos r´esultats.
• La plate-forme TLAPS de preuve interactive est utilis´ee afin de conduire les preuves formelles d´emontrant que les mod`eles IdealPastry et LuPastry v´erifient la propri´et´e CorrectDelivery. Cette preuve montre la correction des mod`eles formels quant `a la propri´et´e vis´ee; elle illustre ´egalement la possibilit´e d’utiliser TLAPS pour une preuve de grande taille impliquant plus de 10000 ´etapes de preuve. • L’´etude de cas qui consiste `a d´emontrer que les mod`eles IdealPastry et
0 R´esum´e ´etendu
0.5 Structure du m´
emoire de th`
ese
La suite de ce m´emoire est structur´ee comme suit. Le chapitre 2 donne un ´etat de l’art concernant les syst`emes P2P et les techniques de v´erification formelle n´ecessaire `a la compr´ehension de ce qui suit.
Le chapitre 3 introduit le protocole Pastry au niveau conceptuel, partant du pseudo-code pour CastroPastry, fond´e sur Castro et al. (2004), en passant par des dia-grammes de flot pour HaeberlenPastry, inspir´e par Haeberlen et al. (2005) et Ideal-Pastry en tant que premier mod`ele formellement v´erifi´e, et aboutissant `a LuPastry, introduit `a nouveau par du pseudo-code et des ´el´ements de sa preuve.
Au chapitre 4 nous introduisons le mod`ele formel de LuPastry et ses propri´et´es de correction. Le chapitre 5 illustre l’utilisation du model checker TLC pour la valida-tion des mod`eles et l’analyse de la propri´et´e de correction. Quelques contre-exemples illustratifs sont pr´esent´es en d´etail. La d´emarche de la preuve d´eductive est introduite au chapitre 6 et appliqu´ee `a la v´erification de HaeberlenPastry, IdealPastry et LuPastry.
Le chapitre 7 introduit d’autres syst`emes P2P r´ealisant des DHT et compare le travail men´e dans cette th`ese avec d’autres approches pour la v´erification de protocoles de r´eseaux.
Au chapitre 8 nous r´esumons cette th`ese en rappelant ses contributions, et nous ´enon¸cons quelques perspectives pour des travaux futurs.
1 Introduction
Pastry (Rowstron and Druschel (2001), Castro et al. (2004), Haeberlen et al. (2005)) is a structured P2P algorithm realizing a Distributed Hash Table (DHT , by Hellerstein (2003)) over an underlying virtual ring of nodes. Several implementations of Pastry are available and have been applied in practice, but no attempt has so far been made to formally describe the algorithm or to verify its properties. Since Pastry is a typical realization of a DHT which combines rather complex data structures, asynchronous communication, concurrency, resilience to churn, i.e. concurrent join and departure of nodes, it makes an interesting target for verification.
This thesis models Pastry’s core algorithms, which provide the correct lookup ser-vice in the presence of churn and maintain a local data structures to adapt the dynamic updates of neighborhood. This chapter starts with the motivation of the research inter-ests, then states explicitly the research goals and explains how these goals are achieved by the work. At the end, a structural guidance will be given for reading the thesis.
1.1 Motivation
In our day-to-day life, disruptions of software systems such as Skype (Microsoft (2013)) directly disturb everyone’s daily life when people cannot make calls, or calls are dropped in the middle of a conversation. Skype is known and used world-wide by billions of users for making phone-calls over Internet. On Thursday, 16th August 2007, the Skype peer-to-peer (P2P ) network became unstable and suffered a critical disruption despite of its peer-to-peer network with an inbuilt ability to self-heal. “This event revealed a previously unseen software bug within the network resource allocation algorithm which prevented the self-healing function from working quickly.” as reported in Arak (2007). Unfortunately on 23rdDecember 2010, millions of users could not make phone calls again due to the departure of several “super nodes”. Is there any fundamental problems of such network design that causes unexpected outage again and again? If not, is there a fundamental proof of its correctness?
Although it is not published how Skype uses the idea of P2P algorithm in its deploy-ments of services, there is no doubt that the scalability of Skype benefits significantly from the adoption of P2P networks, making it feasible to provide billions of phone calls simultaneously world-wide, according to Microsoft (2013). P2P systems have become popular since beginning of 21stcentury with their self-organization and decentralization properties. In particular, structured P2P systems implement Distributed Hash Tables (DHTs), which are supposed to provide
1 Introduction
• distributed maintenance of structure with low costs;
• and resilience to concurrent joins and departures of network members.
For these reasons, DHT is typically used in large-scale distributed systems such as Dynamo (DeCandia et al. (2007)), a storage substrate that Amazon uses internally for many services. Skype may implement DHT for its peers to find each other correctly and efficiently.
However, the correctness of a DHT system relies heavily on its realizing algorithms. Pastry is one of the successful realization1 of DHT . It realizes DHT by mapping object keys (e.g. identifier for a piece of distributed data) to overlay nodes (e.g. the computer connected to the Internet) and offers a lookup primitive to route a message to the node responsible for a key.
Questions About Pastry
Since Pastry implements all properties of a DHT , it is interesting and crucial to under-stand the fundamental mechanisms of Pastry and to analyze and prove its correctness properties. Castro et al. (2004) introduces Pastry on the message level using pseudocode. Starting from this paper, it will be interesting to know the insights of Pastry:
• How does Pastry work, in particular, how does the protocol realized the DHT ? • What does “dependable routing” formally mean? Does Pastry guarantee
depend-able routing? If so, to what extent, and how? Is there any fundamental design flaw in Pastry, in particular Castro et al. (2004), with respect to its correctness properties, such as dependable routing? If yes, how does the problem occur? If not, is there a formal proof?
• Are there other interesting properties of such a system implementing a DHT ? Are they interrelated?
How does Pastry Work
In Pastry, the overlay nodes are assigned logical identifiers from an Id space of naturals in the interval [0, 2M − 1] for some M . The Id space is considered as a ring as shown in Figure 1.1, i.e. 2M − 1 is the neighbor of 0.
The Ids are also used as object keys, such that an overlay node is in particular responsible for keys that are numerically close to its Id, i.e. it provides the primary storage for the hash table entries associated with these keys. Key responsibility is divided equally according to the distance between two neighbor nodes. If a node is responsible for a key we say it covers the key, as illustrated in Figure 1.1.
1
This thesis distinguishes the level of abstraction of an algorithm. Therefore, “realization” is used to described the refinement from DHT to a real algorithm Pastry and “implementation” is used to describe different versions of this algorithm. Both of the words describe different level of details of design and neither of these two words are used in the meaning of executable software.
