Projet : ADP

Précédent : Points de contrôle et retour Remonter : Résultats nouveaux Suivant : Protocoles pour les applications multimedia

   
Contraintes non-fonctionnelles

Participants : Roger Bollo, Eddy Fromentin, Fabiola Greve, Jean-Michel Hélary, Michel Hurfin, Jean-Pierre Le Narzul, Achour Mostéfaoui, Michel Raynal, Frédéric Tronel.

Mots clés : algorithme réparti, résistance aux défaillances, duplication, communication de groupe, temps réel, consensus .

Résumé :

Les travaux réalisés ont essentiellement porté sur le problème du consensus et son utilisation comme brique de base pour résoudre des problèmes d'accord. Un protocole permettant de résoudre efficacement ce problème élémentaire a été proposé. Ce protocole a été adapté afin d'autoriser les pertes de message et les recouvrements. Une nouvelle brique de base, qui généralise le problème du consensus, a été spécifiée et son intérêt pour résoudre des problèmes d'accord a été montré. Une solution au problème du consensus dans un environnement byzantin a été étudiée.

Étant donné que le consensus est utilisé comme une brique de base pour développer l'ensemble des services de groupe, la majeure partie de notre activité de recherche est focalisée sur ce service élémentaire. Quatre actions de recherche complémentaires ont été entreprises:

• Solutions au problème du consensus. Nous nous sommes intéressés aux solutions déterministes s'appuyant sur des détecteurs de défaillances appartenant à la classe ${\diamond{\cal S}}$. Tous les protocoles proposés requièrent qu'une majorité de processus soit constamment en activité. Tous s'appuient sur le paradigme du coordinateur tournant. Un processus exécute une série de tentatives dans le but d'aboutir à une décision commune. Chaque tentative est coordonnée par un processus prédéterminé appelé coordinateur. Le nombre de tentatives effectuées est arbitraire ; il dépend à la fois des occurrences de pannes et du comportement des détecteurs de défaillances.

  Nous avons travaillé sur la définition d'un protocole original utilisant un schéma de communication décentralisé. Chaque processus vote (en diffusant un message) afin de favoriser soit une décision durant la tentative courante, soit un abandon de cette tentative afin de débuter une nouvelle tentative. L'action recevant une majorité de suffrages est finalement exécutée. Les votes (au plus deux) émis par un processus durant une tentative sont régis par un automate simple qui permet d'éviter tout interblocage tout en garantissant l'unicité des valeurs décidées par les processus durant des tentatives éventuellement distinctes. Les détecteurs de défaillances sont fiables durant de longues périodes: les délais de gardes employés sont en effet calculés de façon à ce que les défaillances annoncées soient le plus souvent réelles. Dans ces conditions, cet algorithme simple s'avère être le plus performant (en terme de latence) des algorithmes proposés. Ce protocole est décrit dans le rapport de recherche [HR97].

  L'ensemble de ces travaux nous a conduit à mener une réflexion sur la classification des problèmes dans un environnement asynchrone sujet à des défaillances [[36]].

• Prise en compte de nouveaux types de défaillances. Les solutions actuelles ne permettent de résister qu'à des défaillances de type panne franche. Il s'agit là d'une limitation majeure. Dans ces conditions, il n'est pas réaliste de faire l'hypothèse qu'une majorité de processus sera toujours en activité. Autoriser des recouvrements suite à des pannes nécessite une adaptation des protocoles de consensus afin que la perte de l'état local d'un processus et la perte des messages qui lui ont été adressés puissent être tolérées. Le protocole que nous avons présenté dans [HR97] a ainsi été modifié afin d'autoriser les recouvrements. La solution proposée, qui est décrite dans [[23]], nécessite de stocker peu d'information en mémoire stable.  Nous continuons d'étudier les possibilités de résistance de ce protocole à d'autres types de défaillances. Ainsi, deux nouvelles solutions au problème du consensus dans un environnement byzantin ont été proposées et décrites dans le rapport de stage de DEA de Lénaïck Tanguy (Ifsic Rennes - Septembre 1998). Ces solutions sont également fondées sur le principe du coordinateur tournant.
• Définition d'extensions au problème original. La formulation du problème du consensus est unanimement acceptée et ne fait l'objet d'aucune interprétation anarchique. Il s'agit d'un problème purement théorique qui permet d'abstraire différents problèmes d'accord. La simplicité de ce problème permet, lors de son étude, de se focaliser uniquement sur le résultat d'impossibilité qui est associé à tout problème d'accord. Cependant, rien n'indique que ce problème soit la brique de base idéale pour développer des services de groupe efficaces. Un de nos objectifs est d'évaluer si des extensions au problème original peuvent être proposées afin d'améliorer l'efficacité des services offerts.

  Notre objectif est de converger rapidement vers la définition d'un consensus ``générique'' aisément paramétrable en fonction des problèmes d'accord que l'on souhaite résoudre. Deux voies ont été explorées:

  • La formulation originale du problème du consensus stipule que la valeur décidée est l'une des valeurs proposées. Cette règle peut être adaptée de la façon suivante: la valeur décidée est une collection de valeurs proposées où seules les valeurs initiales émanant de sites suspectés sont susceptibles de ne pas figurer. Les avantages de cette adaptation sont discutés dans [[24]]. Intuitivement, cette adaptation permet de capter un état global partiel unique.
  • Un processus débute sa participation au consensus en proposant une valeur initiale et achève celle-ci lorsque la valeur décidée lui est signifiée. Le fait de ne pouvoir effectuer plusieurs propositions, d'une part, retarde la participation d'un processus jusqu'à ce qu'il ait une valeur significative à proposer et, d'autre part, interdit de compléter cette première proposition avant que le consensus ne soit achevé. En collaboration avec Raimundo Macedo (Université de Bahia, Brésil) et Nadjib Badache (Université d'Alger, Algérie), nous avons étudié l'intérêt des propositions multiples dans le cas particulier d'un environnement composé de stations mobiles ainsi que dans le cas de la diffusion ordonnée.
• Prise en compte de contraintes temporelles. Nous voulons intégrer la notion de contraintes temps-réel dans les solutions proposées pour garantir la sûreté de fonctionnement. Les contraintes temporelles prises en compte sont dites souples au sens où leur non-respect, bien que fâcheux, n'en est pas pour autant catastrophique. Prendre en compte des contraintes temps-réel, nécessite ``à un niveau ou à un autre'', de considérer le temps physique [[25]]. Dans nos travaux, nous considérons une variante du modèle timed asynchronous system défini par Cristian et Fetzer: les processus sont supposés avoir accès à une horloge locale dont la dérive par rapport au temps réel est bornée. L'approche fondée sur l'utilisation de détecteurs de défaillances de la classe ${\diamond{\cal S}}$ ne permet pas de maîtriser le délai nécessaire à une prise de décision en période de fort asynchronisme. Notre objectif est de mieux maîtriser la terminaison du protocole exécuté en permettant de gérer au mieux une durée maximale d'exécution. Pour cela, nous adoptons une approche probabiliste [[35]] qui nous permet, sans remettre en cause la structure interne des protocoles de consensus proposées, de limiter dans le temps la durée des tentatives tout en synchronisant leur déroulement. Le but est alors de déterminer pour un temps maximal souhaité (ou une probabilité de succès donnée) le meilleur couple (nombre de tentatives, durée d'une tentative). Pour réaliser ce calcul, des paramètres caractérisant l'environnement d'exécution (fonction de répartition des délais de transmission des messages, probabilité de perte des messages, probabilité de panne) doivent être pris en compte. Ces travaux récents feront prochainement l'objet de publications.

Précédent : Points de contrôle et retour Remonter : Résultats nouveaux Suivant : Protocoles pour les applications multimedia