Mesures de performances dune primitive de diffusion atomique dans un cluster

Rapport du stage eectuÈ du mai 2007 au 31 octobre 2007 Dans la sociÈtÈ: Laboratoire d'Informatique de Paris Titre du stage: Mesures de performances d'une primitive de diusion atomique dans un cluster LE Anh Duc Encadrement: Marc Shapiro, Directeur de recherche INRIA Pierre Sutra, doctorant INRIA-LIP6 fÈvrier 2008 Remerciements Avant tout dÈveloppement sur cette expÈrience professionnelle, il apparaÓt opportun de commencer ce rapport de stage par des remerciements, ‡ ceux qui m'ont beaucoup appris au cours de ce stage, et mÍme ‡ ceux qui ont eu la gentillesse de faire de ce stage un moment trËs protable Aussi, je remercie le Professeur Marc Shapiro et Pierre Sutra, mes maÓtres de stage qui mÛnt formÈ et accompagnÈ tout au long de cette expÈrience pro-fessionnelle avec beaucoup de patience et de pÈdagogie Enn, je remercie l'ensemble des stagiaires du bureau 849 pour les aides qu'ils ont pu me pro-diguer au cours de ces six mois RÈsumÈ Pour accÈder aux donnÈes partagÈes dans un systËme rÈparti, en mini-misant les passages par le rÈseau, il faut les rÈpliquer Il existe de nombreux algorithmes pour assurer la cohÈrence des rÈplicats en prÈsence de mises ‡ jour, mais ces derniers n'ont pour l'instant jamais fait l'objet d'une compa-raison systÈmatique L'objectif de ce stage est pour Ètudier, simuler, et mesurer les algorithmes de cohÈrence de la littÈrature, en particulier ceux conÁus pour le consensus et la diusion atomique Ce travail s'appuiera sur le framework Appia que l'Èquipe de l'universitÈ de Lisboa dÈveloppe L'Èmulation est lancÈ sur le cluster du groupe REGAL Abstract To access the data shared in a distributed system with the minimum of the passages in the network, the data should be replicated There are many algorithms to ensure the coherence of the data when the replications are updated But it does not exist a comparison of these algorithms The objective of this training course is to study, simulate and measure these algorithms of data's coherence, in particular those are conceived for the agreement problems which are the consensus and the atomic broadcast Then we try to implement and stimulate these algorithms on the Appia fra-mework which is developped by the group of the university Lisboa We run the emulation on the cluster of the REGAL group of LIP6 Table des matiËres Introduction 1.1 1.2 1.3 Bref descriptif du laboratoire ProblÈmatique et objectifs du Annonce de plan Principes de base 2.1 SystËme rÈparti 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 Processus 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 HypothËse de temps 2.3.1 DÈtecteur de dÈfaillances 2.4.1 DÈtecteur de dÈfaillances pa 2.5.1 2.2 2.3 2.4 2.5 ProblËme d'accord 3.1 3.2 Introduction Diusion able 3.2.1 3.2.2 ProblËme consensus 3.3.1 3.3.2 3.3 3.3.3 3.3.4 3.3.5 3.3.6 Diusion atomique 3.4.1 3.4.2 Diusion atomique avec les fa 3.5.1 3.4 3.5 Travaux eectuÈs 4.1 Appia 4.1.1 4.1.2 4.1.3 Cluster DÈploiement l'Appia sur le cl 4.3.1 4.3.2 4.3.3 Mesure de la performance 4.4.1 4.4.2 4.4.3 Modication 4.2 4.3 4.4 4.5 Conclusions et perspectives 5.1 5.2 Conclusions Perspectives Bibliographies Chapitre Introduction 1.1 Bref descriptif du laboratoire Le LIP6 est un laboratoire de recherche sous tutelle de l'UniversitÈ Pierre & Marie Curie, et du CNRS Avec 128 chercheurs permanents et 231 docto-rants, il est l'un des principaux laboratoires de recherche en informatique en France Le laboratoire couvre un large spectre d'activitÈs regroupÈes au sein de cinq dÈpartements : Calcul Scientique ; DEcision, SystËmes Intelligents et Recherche opÈrationnelle ; DonnÈes et Apprentissage Articiel ; RÈseaux et SystËmes RÈpartis ; SystËmes EmbarquÈs sur Puce En complÈment de la recherche acadÈmique, le LIP6 a une longue tradition de coopÈration avec des partenaires industriels dans de trËs nombreux projets nationaux, europÈens ou internationaux Deux centres R&D ont ÈtÈ crÈÈs : le CERME, Centre EuropÈen de Recherche en Micro-Electronique sur les systËmes embarquÈs, et Euronetlab, sur l'internet et les rÈseaux de tÈlÈcommunication Le LIP6 est Ègalement impliquÈ dans les pÙles de compÈtitivitÈ de l'Ile-de-France : Cap Digital sur le contenu numÈrique et System@tic sur les systËmes embarquÈs Il a Ègalement des Èquipes communes avec l'INRIA sur les thÈmatiques du calcul formel et des systËmes rÈpartis La coopÈration internationale est une constante pour les activitÈs du laboratoire Le LIP6 est membre de plusieurs rÈseaux d'excellence et dÈveloppe Ègalement des relations suivies avec des universitÈs au BrÈsil, aux États-Unis, au Japon, et dans de nombreux pays europÈens Le laboratoire est largement ouvert aux projets de coopÈration et ‡ l'accueil de visiteurs scientiques Le laboratoire est impliquÈ dans des enseignements liÈs ‡ la recherche, qui sont dispensÈs au Master "Sciences et technologie" ‡ l'UniversitÈ Pierre et Marie Curie L'EDITE de Paris (Ecole Doctorale d'Informatique, TÈlÈcommunication et Electronique de Paris) ac-cueille ses doctorants REGAL (RÈpartition et Gestion des Applications ‡ Large Èchelle) est une Èquipe commune avec l'INRIA Rocquencourt L'objectif de l'Èquipe est la gestion de ressources dans le cadre trËs dynamique de grands rÈseaux REGAL s'intÈresse aux techniques de dÈploiement d'applications (code et donnÈes) adaptÈes aux environnements extrÍmement distribuÈs de grande taille (nombre de processeurs, distances), fortement dynamiques, hÈtÈrogËnes, sans possibilitÈ simple de gestion centralisÈe et/ou instantanÈe de la connaissance mutuelle L'approche de REGAL repose sur des techniques de rÈplication et d'adaptation dynamique dans lesquelles un code applicatif et ses don-nÈes sont dupliquÈs sur plusieurs sites ce qui permet de tolÈrer les fautes, d'augmenter la disponibilitÈ et rÈduire les temps d'accËs du service rendu par l'application Cet Èquipe Ètudie la faÁon dont les systËmes peuvent ga-rantir une qualitÈ de service en termes de abilitÈ, disponibilitÈ et cohÈrence 1.2 ProblÈmatique et objectifs du rapport Il existe de nombreux algorithmes pour assurer la cohÈrence des rÈplicats des donnÈes partagÈes dans un systËme rÈparti Il a besoin d'une solution pour que tous les instances partagÈes aient les mÍmes dÈcisions ou bien les mÍmes dÈcisions en mÍme ordre L'objectif de ce stage est d'Ètudier ces algorithmes du problËme d'accord Ce sont le consensus et la diusion atomique En suite on observe le code source libre Appia qui a dÈj‡ implÈmentÈ ces algorithmes en langage JAVA On va dÈployer l'Appia sur le cluster du LIP6 En n, on mesure la performance de l'algorithme de la diusion atomique : nombre de messages, nombre des rounds, temps d'exÈcution 1.3 Annonce de plan Ce rapport se compose sections principales La section introduit de l'objetif du stage et un bref descriptif du laboratoire LIP6 La section rap-pelle les notations trËs connues dans un systËme reparti La section prÈsente les problËmes d'accord Dans cette part, on concentre au consensus et ‡ la diusion atomique Ces problËmes d'accord sont observÈs sur l'environne-ment d'un systËme asynchrone avec le dÈtecteur parfait des dÈfaillances La section montre mon travaux Je vais dÈployer l'implÈmentation des algo-rithmes du consensus et de la diusion atomique sur un cluster En suite je mesure la performance de ce systËme : le nombre de messages ÈchangÈs, le nombre de rounds, le temps d'exÈcution Les sections suivantes sont les conclusions, les perspectives et les bibliographies Chapitre Principes de base 2.1 2.1.1 SystËme rÈparti Horloge logique L'horloge logique est dÈnie comme l'assignation un nombre du temps o˘ l'ÈvÈnement s'est produit De maniËre plus prÈcise, une horloge Ci liÈ ‡ un processus Pi est une fonction qui assigne un nombre Ci(a) ‡ n'importe quel ÈvÈnement a dans ce processus Dans cette fonction, l'ÈvÈnement a s'exÈcutÈ avant l'ÈvÈnement b si C(a) < C(b) Cette condition est utile pour dÈterminer l'ordre des messages Èchan-gÈs dans le systËme rÈparti 2.1.2 Horloge physique L'utilisation de l'horloge logique est uniquement utile dans le cas o˘ les ÈvÈnements sont dans un mÍme processus En consÈquence, dans le cas o˘ les ÈvÈnements sont de diÈrents processus, l'horloge physique est souvent utile 2.1.3 Processus et Messages Processus Dans un systËme rÈparti, le processus est dÈni comme les unitÈs qui peuvent exÈcuter des calculs Un processus peut Ítre un processeur, un pro-cessus d'exÈcution, un thread ou un systËme d'exploitation Le processus a les propriÈtÈs suivantes : -Les processus savent de l'un ‡ l'autre -Les processus du systËme se lancent avec le mÍme algorithme -Tous les processus se forment l'algorithme distributÈ Messages La communication entre les processus s'eectue par l'Èchange des messages qui sont uniquement identiÈs par l'identitÈ de ses processus envoyÈ et un nombre d'ordre ou une horloge locale, ainsi que la marque de processus 2.1.4 Automate et Etape Automate Un algorithme A est une collection de n automates dÈterministes L'automate d'un processus reprÈsente sa maniËre d'exÈcution de computation Un exemple de l'algorithme compose de automates : (1) un processus peut recevoir un message qui lui a ÈtÈ envoyÈ, (2) requÈrir son module de dÈtecteur de dÈfaillances, (3) subir une transition d'Ètat, et (4) peut envoyer un message ‡ un processus single Etape Une exÈcution d'un automata d'un algorithme est reprÈsentÈe par un ordre ni des Ètapes dans le cas ni et par un ordre inni des Ètapes dans le cas inni Une Ètape de processus consiste ‡ : - dÈlivrer un message d'un autre processus (ÈvÈnement global) - exÈcuter un calcul local (ÈvÈnement local) - envoyer un message ‡ un certain processus (ÈvÈnement global) L'exÈcution du calcul local et de l'envoi d'un message sont dÈterminÈs par l'automate de processus, c'est-‡-dire, l'algorithme Les ÈvÈnements locaux sont produits par les Ètapes ÈchangÈs entre les modules du mÍme processus aux diÈrentes couches 2.1.5 S˚retÈ et VivacitÈ Pour construire une application ecace et stable, l'algorithme nÈcessite propriÈtÈs suivantes : s˚retÈ et vivacitÈ La propriÈtÈ de s˚retÈ dÈclarent que l'algorithme devrait nous donner le vrai rÈsulat indiquer la source et la destina-tion du message Il a aussi un champ "Message" qui contient les information d'Èchange Appia fournit Ègalement un ensemble de services communs pour simplier les t‚ches du dÈveloppement de protocole, tel que la gestion des tampons de donnÈes des messages (avec des mÈthodes pour ajouter, extraire et inspecter des en-tÍtes), la gestion du temps, la gÈnÈration automatique des ÈvÈnements 29 pour initialiser les canaux 4.1.2 ModËle de l'interaction Le modËle entre les sessions du protocole s'oriente les ÈvÈnements Les ÈvÈnement sont dÈsignÈs pour Ítre recyclÈs de la session ‡ la session Les ÈvÈnements sont triggÈs champs : le canal, la session originale (qui trigge cet ÈvÈnement) et la direction (vers le haut ou le bas) Les champs dÈnissent la chemin des ÈvÈnements Partager les donnÈes entre les sessions sont impossibles Le modËle de l'ÈvÈnement est ouvert Alors, les utilisateurs peuvent dÈnir les nouveaux types de l'ÈvÈnement par l'heritage de la classe "Event" 4.1.3 ModËle concourant Tous les ÈvÈnements de tous canaux dans l'empilage sont traitÈs par un thread single (le thread de programmateur de l'ÈvÈnement) Les dÈveloppeurs ne doivent pas s'inquiÈter de la synchronisation du thread L'Appia dÈnit une classe TimerEvent que la session peut utiliser pour ins-taller le temps Fig 4.3 Modules de protocol pour la diusion atomique 30 Canal able : Ce module du protocole fournit une communication able de messages entre processus localisÈ sur les machines diÈrentes L'in-terface consiste en les ÈvÈnement "envoyer" et "recevoir" DÈtecteur de dÈfaillances : Ce module du protocole implÈmente un dÈtecteur basÈ sur les messages "ping" Consensus : Ce module du protocole implÈmente un algorithme pour rÈ-soudre le problËme de consensus Il interagit avec le dÈtecteur de dÈ-faillances par les ÈvÈnements : start, stop, monitor et suspect Il inter-agit Ègalement avec le canal able Diusion atomique : Ce module implÈmente la diusion atomique Il inter-agit avec le module Consensus et le canal able 4.2 Cluster Le terme cluster peut dÈsigner une grappe de serveurs (ou ferme de cal-cul) de deux serveurs au minimum (appelÈ aussi noeuds) et partageant une baie de disques commune, pour assurer une continuitÈ de service et/ou re-partir la charge de calcul et/ou la charge rÈseau Les propriÈtÈs d'un cluster sont : Les utilisateurs ne savent qu'ils sont en train d'utiliser le cluster Les noeuds ne savent pas que elles sont les parts du cluster Les applications exÈcutant dans le cluster ne savent pas qu'ils sont dans le cluster Les autres serveurs sur le rÈseau ne savent pas qu'ils servent une noeud du cluster Un cluster typique a les caractÈristiques suivantes : -RÈseau : rapiditÈ, connexion plus courte que LAN -Latence bas de communication -Connexion plus faible que les multiprocesseur symÈtriques 4.3 DÈploiement l'Appia sur le cluster L'algorithme est mesurÈ est la diusion atomique avec le dÈtecteur de dÈfaillances parfait P Cet algorithme est simulatÈ pour un systËme asyn-chrone Le dÈtecteur P dois satisfaire propriÈtÈs suivantes : ComplÈtude forte Exactitude forte : Tout processus fautif nit par Ítre soupÁonnÈ par tout processus correct : Aucun processus correct n'est jamais soupÁonnÈ par un autre processus correct 31 4.3.1 Lancement concurrent des processus Quand le systËme s'exÈcute, on a plus de messages traversÈes Il faut mesurer le nombre de messages Il y approches : - Utiliser un outil de systËme (TCPDump) pour capturer et mesurer les pacquages Mais on n'a pas utiliser cette solution ‡ cause de la sÈcuritÈ - Modier dans le codage d'Appia pour calculer le nombre de messages J'ai utilisÈ le secondiËme pour Èviter utiliser le droit "root" ‡ lancer le TCPDump Le laboratoire a plus de projets exÈcutÈs sur le cluster Alors, il y plus de messages inacceptables et inutiles A cause du droit "root", je ne peux pas utiliser le "GEXEC" pour lancer concurremment les processus aux les noeuds de cluster Alors, je dois Ècrire un script en utilisant le protocole ssh pour lancer le programme 4.3.2 PrÈparation avant de l'utilisation ssh L'objet est que l'on peut lancer les processus concurremment L'idÈe est on utilise le ssh pour connecter ‡ chaque noeud du cluster et lancer l'implÈmentation Normalement quand on faire la connexion par le "ssh", le systËme requÈrit le prompt des mots de passe Donc, il dÈpense du temps et les pro-cessus ne s'exÈcutent pas concurremment Alors, il faut faire la prÈparation pour lancer le "ssh" sans le prompt des mots de passe Supposons que on fait connecter du noeud a@A au noeud b@B CrÈer le clÈ RSA a@A : > ssh-keygen -t rsa Cette commande crÈe un pair de la clÈ privÈe et de la clÈ publique dans le rÈpertoire ".ssh" dans la maison "/home/a/.ssh/ Coppier le clÈ publique au noeud b@B La clÈ publique id_rsa.pub est coppiÈ et renommÈ ‡ authorized_keys dans le rÈpertoire "/home/b/.ssh/authorized_ keys" Lancer le ssh a@A : > ssh-agent sh -c 'ssh-add < /dev/null && bash' La commande demande le prompt des mots de passe une fois et aprËs Áa, on peut connecter du a@A au b@B sans le prompt des mots de passe Alors, on peut lancer tous les processus chez les noeuds concurremment pour simuler un systËme rÈparti Mais il faut attention que les noeuds n'ont pas commencÈ en le mÍme temps L'ordre de dÈmarrages dÈpend de l'ordre 32 dans le script 4.3.3 ExÈcution des processuss Le scripts pour lancer la simulation : ssh adle$vServer0 sh testABcast0.sh & ssh adle$vServer1 sh testABcast1.sh & ssh adle$vServer2 sh testABcast2.sh & Le scripts "testABcastx.sh" est pour exÈcuter l'implÈmentation ‡ chaque processus java demo.tutorialDA.SampleAppl -f src/demo/tutorialDA/procs -n 0|1|2 -qos uto La propriÈtÈ "n" est dÈnie l'identitÈ du processus La propriÈtÈ "qos" est dÈnie le type du problËme d'accord utilisÈ : beb - Best Eort Broadcast rb - Lazy Reliable Broadcast urb - All-Ack Uniform Reliable Broadcast iurb - Majority-Ack Uniform Reliable Broadcast pb - Probabilistic Broadcast with a fanout f and a number of rounds r fc - Flooding Consensus hc - Hierarchical Consensus ufc - Uniform Flooding Consensus uhc - Uniform Hierarchical Consensus clc - Carefull Leader Consensus conow - No-Waiting Casual Order conowgc - NoWaiting Casual Order with Garbage Collection cow Waiting Casual Order uto - Consensus-Based Uniform Total Order r1nr Read-One-Write-All Regular (1,N) Register a1nr Read-Impose-Write-All Atomic (1,N) Register annr - Read-Impose Write-Consult Atomic (N,N) Register nbac - Consensus-based Non-Blocking Atomic Commit cmem - Consensus-based Membership trbvs - TRB-based View Synchrony Ici, on utilise l'algorithme la diusion atomique et uniforme, alors, on dois selecter l'option qos "uto" (Consensus-Based Uniform Total Order) 4.4 Mesure de la performance Je vais utiliser l'Appia pour mesurer l'algorithme de la diusion atomique uniforme avec le dÈtecteur P 33 Dans l'Appia, je vois que l'algorithme sous le nom "Consensus-Based Uniform Total Order" (uto) est le mÍme algorithme que l'on a besoin Ci-dessous est le QoS de uto : Fig 4.4 QoS de uto On voit que les lignes (814 - 817) assurent l'algorithme du consensus uniforme avec le dÈtecteur P Alors, les lignes (814 - 818) assurent exactement l'algorithme de la diusion atomique uniforme avec le dÈtecteur P Le uto est un peu diÈrent de l'algorithme dans la page 24 Dans l'Appia, quand un processus connaÓt un crash, il va notier ce crash aux autres processus au lieu de toute la liste de pannes Donc, dans l'Appia, le uto est l'algorithme que l'on a besoin pour mesurer Le cas de test est : • On implÈmente N instances de la diusion atomique sur N noeuds du cluster • Chaque processus propose L messages (N*L = M : nombre total des messsages) • Il n'existe pas de pannes dans ce cas (f=0) • On doit terminer le systËme immÈdiatement par le fonction System.exit() parce que l'Appia donne le systËme marche toujours Donc, le rÈsulat manque quelques dÈcisions T otal_maximal_de_messages = (N ∗ M) + (f + 2) ∗ N ∗ N ∗ M (4.1) N*M : pour diuser les M messages ‡ l'initialisation 34 (f+2)*N*N : pour un consensus d'un message (f+2)*N*N*M : tous processus proposent M messages, donc chaque proces-sus dÈcide M fois de consensus Par example : Nombre de messages pour diuser les 45 messages : M ∗ N = 45 ∗ = 145 ; Nombre de messages pour un consensus : (f + 2) ∗ N = ∗ = 18 Nombre total : M ∗ N + ∗ N ∗ M = 45 ∗ + ∗ ∗ ∗ 45 = 955 messages 4.4.1 Nombre de messages et Nombre des rounds Le cas de test : N=3, L=5 et M=15 Total maximal = 15*3 +2*3*3*15 =315 messages Round Sum Sum Sum decisions m.envoyes m.BEB Le m.BEB est le nombre de messages que les processus doivent envoyer Le m.envoyÈs est le nombre de messages envoyÈs dans le systËme On voit que m.envoyes * N/(N-1)= m.BEB Pour diuser un proposal m, au lieu d'envoyer N messages aux N pro-cessus, un processus seulement envoie (N-1) messages et il n'a pas besoin d'envoyer ‡ soi-mÍme On voit aussi que m.envoyes < 315 messages parce que le systËme est terminÈ immÈdiatement 35 4.4.2 Temps d'exÈcution Le cas de test : N=3, L=5 et M=15 Le temps pour un round de la diusion atomique est commencÈ par la pro-position d'un proposal (ou l'ensemble des proposals) du consensus et est terminÈ par la dÈcision du consensus Je met dans le code source le System.out pour sortir le temps ConsensusUTOSession.java Fig 4.5 Sortir le temps entrÈe d'un consensus J'ai pris les rÈsultats suivants : 36 Fig 4.6 Sortir le temps sortie d'un consensus Round P T P On voit Trounds round T total fois de consensus) 37 4.4.3 Nombre maximal des processus J'ai testÈ que le maximal nombre des processus que le systËme peut rÈ-sister est Quand il y plus de processus concurrent, le systËme est terminÈ immÈ-diatement avec l'exception Null pointer overow L'Appia est un framework de systËme rÈparti dont je ne peux pas dÈboguer l'application normalement mais le System.out J'estime que la raison est la concurrent entre les noeuds de l'Appia Comme les noeuds sont dÈmarrÈs par le script, il existe que un noeud i (i>1) est dÈmarrÈ aprËs le noeud Quand le noeud diuse les proposals, il va attendre les rÈponses du noeud i, mais le noeud i ne nit pas dÈmarrer et ne peut pas dÈlivrer les proposals du noeud i et ne peut pas rÈpondre au noeud Il cause bloquer le systËme parce que le noeud a dÈj‡ envoyÈ les proposals au noeud i et attendu les rÈponse du noeud i, mais le noeud i ne dÈlivre pas ces proposals -> bloquer toujours (Ici on suppose qu'il n'y pas de pannes et on ne dÈmarre pas le dÈtecteur) Fig 4.7 Sortir le temps initial Ici, le di (i=1 n) est l'instant que le processus pi nit le dÈmarrage D'aprËs le gure 4.7 avant le di, le processus pi ne dÈmarre pas complËte- ment et n'est pas prÍt ‡ dÈlivrer les proposals, dont il ne rÈpond pas au p1 AprËs le di, le pi ne proposal du p rÈpond pas au p1 parce que le pi ne dÈlivre pas aucun C'est le bloque qui cause l'exception inconnue et indÈboguÈ 4.5 Modication Je suppose d'amÈliorer l'algorithme en diminuer une condition du commencement d'un round de consensus Mais les rÈsultats que j'ai pris ne sont 38 pas trËs diÈrents L'origine a deux condition pour commencer un nouvel round : il y a les messages dans la queue et le processus n'attend pas le dÈcision du consensus L'amÈlioration est de supprimer la condition d'existance des messages dans la queue 39 Chapitre Conclusions et perspectives 5.1 Conclusions J'ai une vue aspecte sur le problËme d'accord que les reprÈsentants sont le consensus et la diusion atomique J'ai Ègalement ÈtudiÈ le dÈtecteur de dÈfaillances pour capturer les pannes dans un systËme synchrone ou quand mÍme asynchrone J'bserve les approches pour rÈsoudre ces problËmes, ses implÈmentations et je les dÈj‡ deployÈ sur un systËme du cluster On a collectÈ un sondage sur la performance de la diusion atomique 5.2 Perspectives Il faut chercher le maniËre pour augmenter le nombre de processus concur-rents Pour utiliser cette implÈmentation dans le Telex, il faut transformer le programmation de Telex en les composants des automates Si nÈcessaire, on peut construire complËtement une simulation pour faire facilement dÈployer et tester un systËme rÈparti Le cluster est construit pour augmenter la performance d'un group de multiprocesseur, mais il n'y a pas un simulation de test Chaque fois on veut tester une nouvelle solu-tion, on doit refaire au dÈbut toutes les prÈparations inutiles et dÈpenser le temps Une approche est que l'on reutilise le framework Appia pour dÈve-lopper cette simulation An de l'implÈmentation ouverte en Java, l'Appia soit comprÈhensible et facilement ‡ reutiliser Actuellement, la simulation est rÈalisÈ manuellement par les scripts et il manque une programme complËte 40 Chapitre Bibliographies Nancy Lynch Distributed Algorithms Morgan Kaufmann Publisher, Inc San Francisco, California, ISBN 1-55860-3484, pages 103-108,677-680 1996 Rachid Guerraoui and Luis Rodrigues Introduction to Reliable Distri-buted Programming ISBN Spring, 2006 [CT96] T.D.Chandra, S.Toueg Unreliable failure detectors for reliable distributed systems Journal of the ACM, vol 43(2) :225–267, 1996 et Toueg 1996] T.D.Chandra, V.Hadwilacos, S.Toueg The weakest failure detector for solving consensus Journal of the ACM, vol.43, 4, July 1996 M.J.Fischer, N.Lynch, M.S.Paterson Impossibility of Distributed Consen-sus with one Faulty Process Journal of the Association for Computing Machinery, 32(2), pages 374-382, April 1985 M.J.Fischer The consensus Problem in Unreliable Distributed System Proceedings of the International Conference on Foundations of Com-puting Theory, Sweden, 1983 [Hadwilacos J.M.Chang et N.F.Maxemchuk Reliable Broadcase Protocols ACM Transactions on Computer Systems, Vol 2, No 3, pages 251-273, 1983 [Xavier et al.2000] Xavier DÈfago, AndrÈ Schiper, PÈter Urban Total Order Broadcast and Multicast Algorithms : Taxonomy and Survey EPFL Technical report DSC/2000/036, 2000 Xavier DÈfago, AndrÈ Schiper, PÈter Urban Total Order Broadcast and Multicast Algorithms : A comprehensive Survey EPFL Technical report DSC/2000/036, 2000 10 [Lamport 2005] Leslie Lamport Generalized consensus and Paxos Technical Report MSR-TR-È05-33, Microsoft Research, March 2005 11 [Lamport 1989] L Lamport The part-time parliament Tech Report 49, Systems Research Center, Digital Equipment Corp, Palo Alto, Sep 1989 41 12 B.Lampson The ABCDs of Paxos ACM Conference on Principes of Distributed Computing (PODC), 2001, en ligne 13 Xavier DÈfago Agreement-Related problems : From semi-passive re-plication to totally ordered broadcast ThËse N*2229 (2000) 14 PÈter Urban Evaluating the performance of distributed agreement algorithms : tools, methodology and case studies ThËse N*2824 (2003) 15 Alessandro Galleni et David Powell Consensus and Membership in synchronous and asynchronous distributed systems 1996 16 Bernadette Charron-Bost et AndrÈ Schiper Uniform consensus is har-der than consensus (extended abstract) 17 Sergio Mena De La Cruz Protocol composition frameworks and modular group communication : models, algorithms and architectures 18 Flaviu Cristian, Houtan Aghili, Ray Strong, Danny Dolev Atomic Broadcast : From Simple Message Diusion to Byzantine Agreement IBM Alamaden Research Center, Mars 1994 19 Luis Rodrigues et Michel Raynal Atomic Broadcast in Asynchronous Crash-Recovery Distributed Systems Proceedings of the 20th IEEE, Taiwan, April, 2000 20 Gabriel Bracha An asynchronous [(n-1)/3]-resilient consensus proto-col ACM 0-8979/84/008/0154, 1984 21 Cours de R.Baldoni : www.dis.uniroma1.it/ baldoni/ 22 A.Kontostathis, L.E.Holzman, et W.M.Pottenger Use of term Clusters for emerging trend detection 42 ... un message ‡ un processus single Etape Une exÈcution d 'un automata d 'un algorithme est reprÈsentÈe par un ordre ni des Ètapes dans le cas ni et par un ordre inni des Ètapes dans le cas inni Une... obtenues en choisissant une des deux propriÈtÈs de complÈtude et une des quatre propriÈtÈs d'exactitude prÈsen-tÈes dans la section prÈcÈdente La notation rÈsultante de dÈnitions et de correspondance... contient l'identitÈ de l'expÈditeur, et un champ avec un nombre d'ordre ; ces deux champs rendent chaque message unique Dans la diusion faible, un processus diuse un message ‡ un ensemble spÈciÈ de processus