Upload
maxence-villain
View
107
Download
2
Embed Size (px)
Citation preview
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 ?