Problème du Consensus dans les systèmes avec homonymes

Documents pareils
Systèmes et algorithmes répartis

1 Activités d enseignement Enseignements Responsabilités... 5

J2SE Threads, 1ère partie Principe Cycle de vie Création Synchronisation

SSL ET IPSEC. Licence Pro ATC Amel Guetat

Banque Nationale de Belgique Certificate Practice Statement For External Counterparties 1

Tolérance aux fautes - 1 Introduction, techniques de base

Parallélisme et Répartition

Big data : vers une nouvelle science des risques?

Pair-à-Pair: Architectures et Services

La Carte d Identité Electronique

Travail d équipe et gestion des données L informatique en nuage

Poll-O Guide de l utilisateur. Pierre Cros

Liste de conférences et revues Thème Com A

Programmation parallèle et distribuée

Consolidation de stockage

Politique de Certification Pour les Certificats de classe 0 et 4 émis par l autorité de certification Notaires PUBLIÉ

Service SNMP de détection de faute pour des systèmes répartis

Messagerie asynchrone et Services Web

Introduction aux algorithmes répartis

Introduction 1. P1 : Introduction aux bases de données et à Oracle 11g 2. P2 : Administrer Oracle 10g ou oracle 11g 3

Sécurité des applications Retour d'expérience

Transformez votre investissement en source de profit

Université Saint-Joseph. Manuel de pédagogie universitaire. avec le soutien de

Tolérance aux fautes-2 Serveurs à haute disponibilité

Espace de stockage intermédiaire. Compte de Messagerie. Communication «Asynchrone» «Compte de Messagerie»

La sécurité dans les grilles

Ma banque, mes emprunts et mes intérêts

GESTION DE LA RELATION CLIENT (CRM) Etat actuel et perspectives du marché suisse en 2002

CRYPTOGRAPHIE. Chiffrement par flot. E. Bresson. SGDN/DCSSI Laboratoire de cryptographie

Logiciel Libre Cours 3 Fondements: Génie Logiciel

La haute disponibilité

R-ICP : une nouvelle approche d appariement 3D orientée régions pour la reconnaissance faciale

NetCrunch 6. Superviser

Introduction à l informatique temps réel Pierre-Yves Duval (cppm)

Gestion de mémoire secondaire F. Boyer, Laboratoire Sardes

Test de performance en intégration continue dans un cloud de type PaaS

Programmation linéaire

STRICTEMENT CONFIDENTIEL

TOUT SIMPLEMENT UNE PRÉSENCE ACCRUE SUR LE MARCHÉ Regrouper les informations, étendre la portée, accroître les ventes

Le WIFI et l OT vers un wifi territorial. Regards croisés

Le « Pass» : une réponse e-learning à l apprentissage de la messagerie électronique

Les Réseaux sans fils : IEEE F. Nolot

Guide de pratiques exemplaires en matière de commerce mobile. Des techniques concrètes pour surpasser les normes de l industrie

NIMEGUE V3. Fiche technique 3.07 : Sauvegarde / Restauration manuelle

Petite introduction aux protocoles cryptographiques. Master d informatique M2

Le modèle client-serveur

Tarification comparative pour l'industrie des assurances

Les 10 grands principes de l utilisation du data mining pour une gestion de la relation client réussie

MISE EN PLACE DU CONNECTEUR SACOCHE

Les Fiches thématiques la Visio Conférence

HCE & Authentification de seconde génération

Mobile & achats à la demande. Comment le marketing à la performance permet-il aux mobiles d influencer le parcours d achat. tradedoubler.

Joueur B Pierre Feuille Ciseaux Pierre (0,0) (-1,1) (1,-1) Feuille (1,-1) (0,0) (-1,1) Ciseaux (-1,1) (1,-1) (0.0)

ARTICLE. Dix raisons d acheter une caméra réseau ou ce que votre fournisseur de caméras analogiques ne vous révèlera jamais

PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN

Palo Alto Networks Guide de l administrateur Panorama. Panorama 5.1

Les protocoles cryptographiques

GUIDE PRATIQUE DU TRAVAIL COLLABORATIF EN COMMUNAUTES VIRTUELLES D APPRENTISSAGE.

Systèmes de recharge. A chaque application, sa solution. In Charge of E-Mobility.

Plan du cours. Autres modèles pour les applications réparties Introduction. Mode de travail. Introduction

Les Protocoles de sécurité dans les réseaux WiFi. Ihsane MOUTAIB & Lamia ELOFIR FM05

Sommaire. Couverture de zone de surveillance dans les réseaux de capteurs. De quoi parle-t-on ici (1/2)? Objectif. De quoi parle-t-on ici (2/2)?

Introduction au temps réel

Votre Réseau est-il prêt?

Docteur José LABARERE

CONTRAT DE BAIL POUR UN APPARTEMENT Entre : 1. Monsieur... et Madame... domicilies a... ci-apres denomme bailleur - et 2. Monsieur... et madame...

EAI urbanisation comment réussir?

Organisation du module

Compagnie des Transports Strasbourgeois. Innovation : Achat et validation des titres de transport avec un téléphone NFC

Téléinformatique. Chapitre V : La couche liaison de données dans Internet. ESEN Université De La Manouba

Microsoft Application Center Test

Initiation au HPC - Généralités

PRESENTATION DES RECOMMANDATIONS DE VANCOUVER

Exclusion Mutuelle. Arnaud Labourel Courriel : arnaud.labourel@lif.univ-mrs.fr. Université de Provence. 9 février 2011

L identité numérique. Risques, protection

DAns un système multi-utilisateurs à temps partagé, plusieurs processus

ÉNONCÉ DE PRINCIPES LE COMMERCE ÉLECTRONIQUE DES PRODUITS D ASSURANCE

L USAGE DES NEWSLETTERS BtoB. Enquête exclusive Niouzeo Septembre 2011

OPTENET DCAgent Manuel d'utilisateur

Plan. 5 Actualisation. 7 Investissement. 2 Calcul du taux d intérêt 3 Taux équivalent 4 Placement à versements fixes.

Prérequis. Résolution des problèmes WMI. Date 03/30/2010 Version 1.0 Référence 001 Auteur Antoine CRUE

Conception et contrôle des SMA tolérants aux fautes

easiware lance easicrm lead nurturing

Livre Blanc. ETL Master Data Management Data Quality - Reporting. Comment mieux connaître et maîtriser son réseau de distribution indirect?

RAPPORT DE STAGE DE MASTER INFORMATIQUE DE L UNIVERSITE PIERRE ET MARIE CURIE Sécurité des infrastructures critiques.

POUR LES PETITES ET MOYENNES ENTREPRISES INDUSTRIELLES

LIVRE BLANC WiFi PUBLIC

visio-rendezvous.fr Rapprochons le service public des usagers mise en relation à distance mise en relation à distance téléconseiller

DATE D'APPLICATION Octobre 2008

Workflow et Service Oriented Architecture (SOA)

MORPHO CRIMINAL JUSTICE SUITE

Haute Disponibilité de l environnement WMQ Outils & Méthodes

Premier Accelerate Packages: Azure Fast Start

ROUTEURS CISCO, PERFECTIONNEMENT

Réduire des dommages de force, optimiser le parc de véhicules PLUS DE SECURITE MOINS DE FRAIS. Technologie de

Machines virtuelles Cours 1 : Introduction

CEG4566/CSI4541 Conception de systèmes temps réel

Souad EL Bernoussi. Groupe d Analyse Numérique et Optimisation Rabat http ://

Master e-secure. VoIP. RTP et RTCP

Protocole de configuration dynamique des hôtes pour IPv6 (DHCPv6)

Transcription:

Problème du Consensus dans les systèmes avec homonymes Hung Tran-The Réunion Displexity La Rochelle, Avril 2013 1

Plan Systèmes répartis classiques Modèle Homonyme Problème du Consensus Résultats Conclusion 2

Systèmes répartis classiques Système réparti: un ensemble de processus + un réseau de communication. Systèmes avec les identités uniques: identités distinctes. Systèmes anonymes: aucune identité. 3

Systèmes avec les identités uniques Avantage: faciliter la détermination des expéditeurs et récepteur des messages. Désavantages: Difficulté de tenir les identités de tous les processus distincts. Le nombre de processus augmente. Le système peut accidentellement affecter la même identité à des processus différents. Attaques Sybilles: Des processus malveillants peuvent usurper des identités des autres processus. Systèmes P2P [John R. Douceur 02]. Un attaque dans système P2P Maze [LZYDL 07]. Réseaux de capteurs [NSSP 04]. 4

Système anonyme Introduit par Angluin [STOC80] Applications: Web servers [RR98], Réseau de capteurs [TKR05], P2P [AVML05]. Avantage: protéger la vie privée des utilisateurs Désavantage: peu de problèmes peuvent être résolus. Impossibilité de l élection de leader [STOC80]. Impossibilité du problème de comptage dans un réseau inconnu avec une diffusion et sans leader [MCS12]. Impossibilité du problème de nommage même avec un leader [MCS12]. Impossibilité du problème du consensus: [AFR06], [PS90] 5

Système anonyme Difficulté de briser la symétrie en présence: l anonymat, l asynchronie, des pannes? Impossibilité de l élection de leader: anonymat + anneau (synchronie) anonymat + asynchronie (n importe quelle topologie) Impossibilité du consensus: asynchrone + panne crash [FLP80] anonymat + panne malveillante (synchronie) [Okun05] 6

Systèmes avec identité uniques: Dificulté de tenir la distinction des identités Attaques sybille Systèmes anonymes: Peu de problèmes peuvent être résolus. Système avec homonymes 7

Modèle avec homonymes Modèle général incluant les 2 modèles de système: système avec identités uniques et système anonyme. n processus utilisent Ɩ identités où 1 Ɩ n 8

Exemple: n = 4, Ɩ = 2 1 2 3 4 Système avec identités uniques Système anonyme 1 1 1 2 2 2 2 2 2 1 1 1 Distribution d identités dans le système avec homonymes 9

Exemple LIAFA ASAP LABRI 10

Modèle avec homonymes Les processus sont divisés en groupes. Chaque groupe a une identité unique. Les processus dans une groupe (homonymes) utilisent la même identité. Les homonymes exécutent des algorithmes identiques. Un processus peut envoyer des messages à un groupe mais ne peut pas envoyer à un processus particulier. Un processus ne peut pas déterminer si un message reçu vient d un processus ou vient de processus différents ayant la même identité. 11

Motivation D un point de vue pratique: Moins de confidentialité, mais plus de problèmes peuvent être résolus (briser la symétrie). Utile si certains processus sont affectés à la même identité ou des processus byzantins usurpent l identité des autres processus. (aucun algo classique compte ça) D un point de vue théorique: comprendre l'importance de l'identité en informatique distribuée. 12

Quels problèmes peuvent être résolus dans les systèmes avec homonymes? 13

Consensus On utilise le problème du consensus pour étudier la puissance des systèmes par messages avec homonymes. Chaque processus propose une valeur. Chaque processus décide une valeur telle que: Accord: Si deux processus corrects décident ils décident la même valeur. Validité: toute valeur décidée est l une des valeurs proposées. Terminaison: tout processus correct décide au bout d un temps fini. Plusieurs variantes: Pour le modèle des pannes byzantines: Validité: si tous les processus corrects ont la même valeur proposée v alors v est valeur décidée (Consensus byzantin). Consensus uniforme: Accord Uniforme: si deux processus (correct ou non) décident, ils décident la même valeur. 14

Modèle n processus Ɩ identités au plus t processus en panne Système par message: Synchrone: bornes supérieures de communication connues => rondes synchrones: émission, réception et calcul. Partiellement synchrone [DLS88]: Commutation en rondes synchrones. Il existe un temps T tel que après T, tous les messages diffusés par les processus sont délivrés. Des messages peuvent ne pas être délivrés avant T. Canal fiable: il ne crée pas, ni duplique ni modifie des messages. 15

Défaillances Panne franche (crash) Panne par omission d émission (send omission) Panne par omission d émission ou de réception (general omission) Panne Byzantine: comportement arbitraire. 16

Modèle On considère 2 cas: Les processus peuvent compter des messages identiques dans une ronde (numerate processes) Les processus ne peuvent pas compter des messages identiques dans une ronde (innumerate processes) 17

Travaux concernés Consensus: Consensus uniforme: 18

Résultats: Cas synchrone Conditions nécessaires et suffisantes pour le consensus (n processus,ɩids, au plus t processus byzantins) Anonyme Ɩ = 1 Crash Send-omission n t General-omission Byzantine? Impossible [Okun05] Homonyme Innumerate Ɩ < n Numerate Ɩ 1, n t Ɩ > 2t Ɩ > 3t Ɩ 1, n t Ɩ 1, n > 2t Ɩ > 3t IDs uniques n t n > 2t n > 3t Ɩ = n [PSL80] Consensus uniforme 19 Consensus byzantin

Cas partiellement synchrone En présence de la synchronisation partielle, des pannes byzantines et des homonymes, la condition nécessaire et suffisante pour le consensus est: l > (n+3t)/2 20

LIAFA ASAP LABRI 21

Le consensus peut être résolu dans le système avec homonymes. Les identités ne sont pas nécessaires pour résoudre le consensus si des pannes sont des pannes franches, des pannes par omission d émission ou réception (pannes bénignes). Les identités sont nécessaires avec des défaillances Byzantines: l 3t+1 (la borne inférieure). La solution dépend du nombre d identités, pas du nombre de processus. Augmenter le nombre de processus corrects n améliore rien. 22

Dans le cas partiellement synchrone: l > (n+3t)/2 Le nombre d identité est presque même que le nombre de processus. Augmenter le nombre de processus corrects peut rendre l accord impossible. 23

Publié à ICDCN13, PODC11, DC journal Cas synchrone: Consensus uniforme avec des pannes bénignes: solution en t+1 rondes (optimale). Consensus avec des pannes byzantines: solution générique: transformer (l processus, l identités) en (n processus, l identités). Cas partiellement synchrone: Impossibilité: l argument d indistingabilité. Possibilité: basé sur l algorithme Dwork-Lynch- Stockmeyer [DLS88]. 24

LIAFA ASAP LABRI 25

Impossibilité Cas partiellement synchrone Si l (n+3t)/2, impossible! Par exemple: 5 processus affectés à 4 identités, un processus byzantin. 26

Scénario 1: Tous les messages sont délivrés. Le processus byzantin ne fait rien. Tous les processus corrects proposent la valeur 1. Par la validité, tous les processus correctes décident 1, après r 1 rondes. Byzantin 1 1 1 1 Décider 1 27

Scénario 1: 1 1 1 1 Byzantin Décider 1 Scénario 2: 10 10 1 10 10 Byzantin Décider 0 28

Scénario 3: Les messages entre les deux groupes de processus corrects ne sont pas délivrés en temps suffisamment longue. Le processus byzantin envoie plusieurs messages à des processus. 1 1 byzantin 10 10 29

Scenario 1 1 1 1 1 Scenario 3 1 1 1 1 10 10 1 10 10 byzantin Scenario 2 10 10 1 10 10 30

Scenario 1 1 1 1 1 Décider 1 Scenario 2 10 10 1 10 10 Décider 0 Scenario 3 1 1 1 1 10 10 1 10 10 byzantin Décider 1 Décider 0 Accord: la valeur décidée est la même pour tous les processus corrects. 31

Algorithme en synchronie partielle La preuve basée sur l algorithme Dwork-Lynch- Stockmeyer. Utiliser la diffusion authentifiée [Srikanth, Toueg]. Difficultés: les homonymes envoient des messages contradictoires. Solution: Utiliser des quorums l-t ids. Un groupe leader au lieu d un leader. Des messages supplémentaires pour aider les processus corrects dans des groupes contenants des processus byzantins à décider. 32

Consensus avec pannes byzantines limitées Restriction: le processus byzantin ne peut pas envoyer plusieurs messages au même processus dans une ronde. 33

Homonymes avec la distribution d identité disponible Distribution d identités: n = (n 1, n 2,, n l ) Mode de pannes: t = (t 1, t 2,, t l ) Groupe correct, partiellement byzantin, byzantin. Coefficient d accord: c i = n i si G(i) est correct. c i = 1 si G(i) est partiellement byzantin et c i = 0 si G(i) est byzantin. 34

Homonymes avec la distribution d identité disponible Condition nécessaire et suffisante pour le consensus: c = Min{c 1 + c 2 + + c l } > 2t Par exemple: si n i > t, l > t est suffisant pour le consensus. On fixe n, l, t. I, il existe une distribution d identités pour le consensus si et seulement si: l > (n-r)t/ (n-t-min(r,t)) où r = mod l Publié à ICDCN12, TCS 35

Homonymes avec des identités usurpées Des processus byzantins peuvent usurper un ensemble d identités F: F =k. Sans authentification: l> 2t + k Avec authentification: l> t + k Publié à SIROCCO12 36

Conclusion L identité est nécessaire dans les systèmes avec pannes byzantines mais pas nécessaire dans les systèmes avec pannes bénignes. Contrairement aux systèmes classiques avec identités uniques, dans les systèmes avec homonymes, augmenter des processus corrects peut rendre l accord impossible. 37

Conclusion Deux méthodes pour réduire nombre d identités: Restreindre la puissance des processus byzantins. Connaître la distribution d identités. 38

Conclusion Tout problème peut-il être résolu avec peu d identité? Solvabilité + confidentialité: système avec homonymes peut-il remplacer les systèmes classiques? 39