1 ACI DADDI - Réunion de lancement IRISA - Projet ADEPT Michel Hurfin Jean-Pierre Le Narzul Frédéric Tronel 23 mai 2005

2 Plan de la présentation 1. Le projet ADEPT 2. Participation à lACI DADDI Personnes impliquées Activités (modèle explicite) 3. Questions

3 Le projet ADEPT Solutions algorithmiques pour des systèmes dynamiques s û rs de fonctionnement

4 Communauté de calculateurs Plusieurs calculateurs Un médium de communication Des interactions entre calculateurs applications réparties (coopération à la réalisation dune tâche commune) Délocalisation des données Délocalisation des calculs

5 Lenvironnement de calcul Différentes caractéristiques Hétérogénéité (puissance, énergie, …) Mobilité physique et logique Taille (nombre de calculateurs) Modèle de calcul Modèle de défaillances

6 Modèle de calcul Synchrone Référentiel de temps commun Réactivité connue au travers de bornes Temps de transfert dun message Temps dexécution dun pas de calcul Asynchrone Pas dhypothèse temporelle Partiellement synchrone

7 Modèle de défaillances Canaux de communications fiables duplication / altération / perte Calculateurs Pas de défaillance Pannes franches Fautes domissions Fautes byzantines

8 Problématique générale Environnement (hypothèses) Problème (propriétés) Solutions (métriques)

9 Thèmes de recherche S û ret é de fonctionnement Disponibilité des données Dissémination de linformation Petits groupes de calculateurs Grilles de calculs P2P Réseaux de capteurs

10 Participation à lACI DADDI Michel Hurfin (CR INRIA) Jean-Pierre Le Narzul (MdC ENST Br) Frédéric Tronel (MdC Rennes I) ? (Ingénieur Expert)

11 Modèle implicite (1) Proxy / IDS Plusieurs variantes du serveur S Client Une variante au plus peut être alt é r é e par une attaque nouvelle

12 Modèle implicite (1) Comparaison des réponses retournées Existence de différences Différence dans les spécifications Spécifications incomplètes Erreurs de conception Attaque réelle n variantes et au plus t attaques Identification éventuelle de la variante attaquée (si par exemple t=1 et n=3)

13 Modèle implicite (2) Proxy / IDS Plusieurs variantes du serveur S Client Une variante et un proxy au plus peut être alt é r é e par une attaque nouvelle

14 Modèle implicite (2) t proxys peuvent subir des attaques Équilibrage de charge Ordonnancement des requêtes à g é rer Accord unanime malgr é les d é faillances de proxys

15 Concept de groupe Une petite communauté de calculateurs Évolution dynamique de la composition du groupe Opération Joindre Opération Quitter Communication via des primitives de diffusion à destination de tous les membres du groupe Ordre causale Ordre total (diffusion atomique)

16 Réplication Active Client AClient B Proxys et serveurs P & S

17 Composition du groupe Gestion de lévolution dynamique de la composition du groupe (ajouts, retraits, pannes) Vue du groupe V0 Join Leave Vue du groupe V1

18 Gestion de la composition du groupe Accord sur les vues calculées et sur lordre dinstallation des vues p r s q join V1 = {p,q,s} V0 = {p,q,r} V0 V1

19 Diffusion ordonnée Différents ordres de réception Construire lordre total de livraison des messages p r s q V0 V1

20 Synchronisation des vues Quand installer une vue ? Même ensemble de messages entre deux vues consécutives p r s q V0 V1 Msg(p) = Msg(q)

21 Le problème du consensus P1P2PiPn v1v2vivn d d d d

22 Consensus générique Solution adaptative: Différentes propriétés de validité Souplesse dutilisation: Soumettre des propositions multiples Identification des besoins dune application en terme daccord (paramètres). Prise en compte de la sémantique des valeurs Bibliothèque de composants daccord.

23 Bibliothèque de composants VIEW SYNCHRONY ATOMIC BROADCAST GROUP MEMBERSHIP Generic CONSENSUS FAILURE DETECTOR ROUND SYNCHRONIZER

24 FIN Choix, Interactions, Planning, … Questions ?