1

ACI DADDI - Réunion de lancement

IRISA - Projet ADEPTMichel Hurfin

Jean-Pierre Le NarzulFrédéric Tronel

23 mai 2005

2

Plan de la présentation

1. Le projet ADEPT2. Participation à l’ACI 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 d’une tâche commune)

Délocalisation des données Délocalisation des calculs

5

L’environnement 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 d’un message Temps d’exécution d’un pas de calcul

Asynchrone Pas d’hypothè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 d’omissions 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 l’information

Petits groupes de calculateurs Grilles de calculs P2P Réseaux de capteurs

10

Participation à l’ACI 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 auplus peut êtrealtérée par uneattaque 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 etun proxy auplus peut êtrealtérée par uneattaque 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 A Client 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 l’ordre d’installation 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 l’ordre 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

V1Msg(p) = Msg(q)

21

Le problème du consensus

P1 P2 Pi Pnv1 v2 vi vn

dd d d

22

Consensus générique Solution adaptative:

Différentes propriétés de validité Souplesse d’utilisation:

Soumettre des propositions multiples Identification des besoins d’une

application en terme d’accord (paramètres). Prise en compte de la sémantique des valeurs

Bibliothèque de composants d’accord.

23

Bibliothèque de composants

VIEWSYNCHRONY

ATOMICBROADCAST

GROUPMEMBERSHIP

GenericCONSENSUS

FAILUREDETECTOR

ROUNDSYNCHRONIZER

24

FIN

Choix, Interactions, Planning, …

Questions ?