Transcript 1 - Verimag
Ingénierie des Protocoles Stéphane Devismes Infos pra8ques • Contact : [email protected] • Web : www-‐verimag.imag.fr/~devismes/WWW/enseignements.html • Contact promo : Ricm5-‐[email protected] • Salles de Cours/TD/TP, voir planning sur mon site Ingénierie des protocoles 2 But • Algorithmes distribués : – – – – Spécifica8on Concep8on Preuve de correc8on et complexité Implanta8on • Dans le simulateur Sinalgo • Source (plug-‐in Java), Tutorial et supports disponibles sur ma page Web) • Problèmes considérés : briques de bases pour les réseaux – élec8on, circula8on de jeton, diffusion, etc. • Intérêt et inconvénient : Indépendant de l’architecture matérielle Ingénierie des protocoles 3 Contenu • 11 semaines, 40 heures • Alternance Cours-‐TD / TP • Suite du cours « Algorithmique Distribuée » de RICM4 • Aspect « tolérance aux fautes » Ingénierie des protocoles 4 Plan du cours • Rappel « Algorithmique non tolérante aux fautes » – 4 heures • Introduc8on à la tolérance aux fautes + bit alterné – 4 heures • Consensus, impossibilité (FLP) et algorithmes – 12 heures • Auto-‐stabilisa8on – 18 heures Ingénierie des protocoles 5 Evalua8on • • • • Examen 2h Fin janvier Annales disponibles sur ma page Web Ingénierie des protocoles 6 Introduc8on Ingénierie des protocoles 7 Algorithmes distribués Ingénierie des protocoles 8 Algorithmes distribués • Algorithmes pour des systèmes distribués J • « En informa8que, un système distribué (aussi appelé système répar8) est un ensemble d ’ u n i t é s d e t r a i t e m e n t a u t o n o m e s interconnectées entre-‐elles. » – Gérard Tel, Introduc=on to distributed algorithms Ingénierie des protocoles 9 Algorithmes distribués • Système distribué ≃ modélisa8on des réseaux – Internet – Le réseau de l’Université – Le réseau téléphonique (filaire, cellulaire) – GPS – Réseau de capteurs (surveillance sismique) – Threads sur une machine – ... Ingénierie des protocoles 10 Algorithmes distribués • Unités de traitement = processus = processeurs = nœuds Ingénierie des protocoles 11 Algorithmes distribués • Autonome : – Chaque machine est pourvue de son propre contrôle • Programmes locaux • Mémoires locales Ingénierie des protocoles 12 Algorithmes distribués • Autonome : – ≠ algorithmes parallèles : pas de synchronisa8on (logicielle ou matérielle) • Asynchrone • Pas de temps global Ingénierie des protocoles 13 Algorithmes distribués • Interconnectées : échanges d’informa8ons Ingénierie des protocoles 14 Algorithmes distribués • Interconnectées Ingénierie des protocoles 15 Algorithmes distribués • Interconnectées : échanges d’informa8ons – via messages Ingénierie des protocoles 16 Algorithmes distribués • Interconnectées : échanges d’informa8ons – Couches de communica8on (Modèle OSI) U8lisateur final Applica>on Présenta>on Session Transport Réseau MAC Physique Deux fonc8ons : -‐ Envoyer(M,v) -‐ Recevoir(M,v) Protocoles réseaux : Algorithmes distribués Envoi d’une trame de bits (message) point à point Envoi d’un seul bit d’informa8on point à point Ingénierie des protocoles 17 Centralisé vs. Distribué Ingénierie des protocoles 18 Centralisé vs. Distribué • Absence de connaissance globale – Pas d’accès à l’état global du système – Décisions basées la mémoire locale du nœud • Mise à jour en fonc8on des échanges d’informa8ons • Problème de pérennité des informa8ons (système asynchrone) Racine = faux Ingénierie des protocoles 19 Centralisé vs. Distribué • Absence de temps global: – Temps d’exécu8on des nœuds ≠ – Communica8ons asynchrones – Horloges locales ≠ (valeurs ini8ales ≠ + dérive) – Conséquence : contrairement aux systèmes centralisés, l’ordre (observable par les processus) entre les ac8ons des processus n’est que par8el : l’ordre de causalité • (Lamport 1978) Ingénierie des protocoles 20 Causalité : exemple p m q • L’événement « p envoie m » arrive avant l’événement « q reçoie m » Ingénierie des protocoles 21 Causalité : exemple c p m q • L’événement « p envoie m » arrive avant l’événement « p effectue le calcul interne c » Ingénierie des protocoles 22 Causalité : exemple p m m’ q • Les événements « p envoie m » et « q envoie m’ » sont indépendants Ingénierie des protocoles 23 Centralisé vs. Distribué • Non-‐déterminisme – Algorithme déterministe séquen8el : sor8es fonc8on des entrées – Algorithme déterministe distribué : pour les mêmes entrées, plusieurs résultats peuvent être possible Ingénierie des protocoles 24 Exemple 2 1 Sor8e = premier message reçu – deuxième message reçu Résultat ? Ingénierie des protocoles 25 Caractéris8ques d’un système distribué : sa topologie Ingénierie des protocoles 26 Caractéris8ques • Topologie = réseaux d’interconnexion • Topologies ≈ Graphe (simple) G=(V,E) – 2 processus qui peuvent communiquer directement = voisin – Communica8ons : • bidirec8onnelles (ex., réseaux filaires) ou • unidirec8onnelles (ex., réseaux à fibres op8ques) – Généralement on supposera des communica8ons bidirec8onnelles et une topologie connexe Ingénierie des protocoles 27 Les systèmes distribués • Hypothèses – Liens bidirec8onnels Ingénierie des protocoles 28 Liens bidirec8onnels : pas toujours ! Ingénierie des protocoles 29 Rappel : Connexité Connexe ! Ingénierie des protocoles 30 Rappel : Connexité Pas connexe ! Ingénierie des protocoles 31 Exemples de topologies anneau arbre étoile Ingénierie des protocoles clique 32 Caractéris8ques d’un système distribué : liens de communica8ons Ingénierie des protocoles 33 Communica8ons • Par message (modèle à passage de message) – Fiabilité du canal • (fiable ou avec perte équitable ou taux de livraison ou dynamique) • Fiable = pas de perte, duplica8on, créa8on – Ordre d’arrivée des messages • (FIFO ou non) – Capacité des canaux • (borné ou pas, borne connue ou pas) – Temps d’acheminement (toujours fini) • (synchrone, asynchrone, finalement synchrone) • (pour les deux derniers, borne connue ou pas) – Temps de traitement (supposé) négligeable Ingénierie des protocoles 34 FIFO : Rappel Ingénierie des protocoles 35 FIFO : Rappel A Ingénierie des protocoles 36 FIFO : Rappel B A Ingénierie des protocoles 37 FIFO : Rappel C B A Ingénierie des protocoles 38 FIFO : Rappel C B Ingénierie des protocoles A 39 FIFO : Rappel C Ingénierie des protocoles B 40 FIFO : Rappel C Ingénierie des protocoles 41 Temps d’acheminement 1. Un canal est synchrone s’il existe une constante c telle que pour tout temps t, si un message est émis au temps t alors il est reçu avant le temps t + c ou perdu. 2. Un canal est finalement synchrone s’il existe un temps t et une constante c telle que pour tout temps t’ ≥ t, si un message est émis au temps t’ alors il est reçu avant le temps t’ + c ou perdu. 3. Un canal est asynchrone s’il n’existe pas de temps t et de constante c telle que pour tout temps t’ ≥ t, si un message est émis au temps t’ alors il est reçu avant le temps t’ + c ou perdu. Ingénierie des protocoles 42 Caractéris8ques d’un système distribué : les processus Ingénierie des protocoles 43 Caractéris8ques • Processus – Ini=ateur (démarrage « spontané ») ou non-‐ ini=ateur (aussi appelé suiveur, démarrage suite à une communica8on avec un voisin) – Sujet ou pas aux pannes ? (et quel type ?) – Asynchrone (équitable), synchrone ou finalement synchrone – Mémoire locale de taille bornée ou non ? Ingénierie des protocoles 44 Caractéris8ques d’un système distribué : le temps Ingénierie des protocoles 45 Caractéris8ques • Temps (global) – Discret : temps 0, 1, 2 … – Non accessible aux processus mais u8lisé dans les preuves – Cependant, on u8lisera parfois du temps local (minuteurs) Ingénierie des protocoles 46 Caractéris8ques d’un système distribué : connaissances ini8ales des processus Ingénierie des protocoles 47 Caractéris8ques • Connaissances ini>ales (entrées) des processus – Propriétés globales : • Topologique : borne supérieure ou exacte sur – Le nombre de processus (n) – Le degré maximum (Δ) – Le diamètre du réseau (D) • Dis8nc8on entre les processus – Anonyme – Iden8fié – Semi-‐anonyme » Enraciné Ingénierie des protocoles 48 Réseaux iden8fiés : Rappel 4078 167 • Iden8té unique (e.g., adresse IP) 12 42 23 Ingénierie des protocoles 49 Réseaux enracinés : Rappel Ingénierie des protocoles 50 Réseaux enracinés : Rappel Racine = vrai Racine = faux Racine = faux Racine = faux Racine = faux Ingénierie des protocoles 51 Caractéris8ques • Connaissances ini>ales des processus – Propriétés locales : connaissance sur le voisinage • Degré local ? • Iden8té des voisins ? • Numéro de canaux (é8quetage local) ? • Rien ? (ex. réseaux sans fils) Ingénierie des protocoles 52 Numérota8on des canaux 1 2 3 1 4 3 1 3 4 2 2 2 2 1 1 1 3 2 2 3 1 3 Ingénierie des protocoles 53 Exemple récapitula8f Ingénierie des protocoles 54 Algorithme Distribué Exemple : Calcul d’un arbre couvrant Ingénierie des protocoles 55 Algorithme Distribué Exemple : Calcul d’un arbre couvrant Ingénierie des protocoles 56 Algorithme Distribué Exemple : Calcul d’un arbre couvrant Ingénierie des protocoles 57 Algorithme Distribué Exemple : Calcul d’un arbre couvrant Racine = vrai Racine = faux • Entrées répar8es Racine = faux Racine = faux Racine = faux Ingénierie des protocoles 58 Algorithme Distribué Exemple : Calcul d’un arbre couvrant • Entrées répar8es • Calculs locaux Racine = faux – Mémoires locales – Programmes locals – Envoi de messages – Décision locale Ingénierie des protocoles 59 Algorithme Distribué Exemple : Calcul d’un arbre couvrant Racine = vrai Racine = faux – Mémoires locales – Programmes locals – Envoi de messages – Decision locale Racine = faux Racine = faux • Entrées répar8es • Calculs locaux Racine = faux • Sor8es répar8es Ingénierie des protocoles 60 Algorithme Distribué Exemple : Calcul d’un arbre couvrant Racine = vrai Racine = faux – Mémoires locales – Programmes locals – Envoi de messages – Decision locale Racine = faux Racine = faux • Entrées répar8es • Calculs locaux Racine = faux • Sor8es répar8es • Tâche globale Ingénierie des protocoles 61 Analyse de complexité Ingénierie des protocoles 62 Complexité • Pire des cas, cas moyen, meilleur des cas • Exact ou asympto8que (nota8on de Landau) • Calcul interne négligeable Ingénierie des protocoles 63 Mesures de complexité • Complexité en messages • Complexité en volume • Complexité en temps – Temps de traitement = 0, temps d’acheminement = 1 • Complexité en espace (bits ou états) Ingénierie des protocoles 64 Problèmes classiques Ingénierie des protocoles 65 Problèmes classiques • Echange de donnée : routage, diffusion, … • Accords : consensus, élec8on, … • Auto-‐organisa>on : arbre couvrant, clustering • Alloca>on de ressources : exclusion mutuelle, diner des philosophes… Ingénierie des protocoles 66 Echange de donnée : routage Ingénierie des protocoles 67 Echange de donnée : routage Source Des>na>on Ingénierie des protocoles 68 Echange de donnée : routage Ingénierie des protocoles 69 Accord : élec8on Calculer un chef ! (avec publica8on ou non) Ingénierie des protocoles 70 Accord : élec8on Calculer un chef ! 34 12 15 22 31 Ingénierie des protocoles 42 58 56 72 71 Accord : élec8on Calculer un chef ! (avec publica8on) 12 34 12 12 12 42 12 12 15 12 22 31 12 Ingénierie des protocoles 12 58 56 72 12 72 Auto-‐organisa>on : k-‐Clustering Ingénierie des protocoles 73 Auto-‐organisa>on : k-‐Clustering Ingénierie des protocoles 74 Auto-‐organisa>on : k-‐Clustering • Ex. k=2 ≤k Ingénierie des protocoles 75 Auto-‐organisa>on : k-‐Clustering • Ex. k=2 ≤k Ingénierie des protocoles 76 Alloca>on de ressources : exclusion mutuelle Ingénierie des protocoles 77 Alloca>on de ressources : exclusion mutuelle Ingénierie des protocoles 78 Alloca>on de ressources : exclusion mutuelle Ingénierie des protocoles 79 Alloca>on de ressources : exclusion mutuelle Ingénierie des protocoles 80 Alloca>on de ressources : exclusion mutuelle Ingénierie des protocoles 81 Exemple trivial : Exclusion mutuelle de Le Lann Ingénierie des protocoles 82 Méthodologie 1. 2. 3. 4. Spécifier le problème à résoudre Fixer les hypothèses sur le système Ecrire un algorithme Prouver que l’algorithme vérifie la spécifica8on sous les hypothèses fixées 5. Etudier la complexité 6. Implanter l’algorithme Ingénierie des protocoles 83 Spécifica8on • Enoncé formel du problème que l’algorithme doit résoudre • Sûreté (safety) + Vivacité (Liveness) – Sûreté : l’ensemble des propriétés qui doivent être vérifiées à chaque instant de l’exécu8on de l’algorithme. « Rien de mal ne doit arriver. » – Vivacité : L’ensemble des propriétés qui doivent être vérifiées à certains instants de l’exécu8on de l’algorithme. « Quelque chose de bien finit par arriver. » Ingénierie des protocoles 84 Spécifica8on de l’exclusion mutuelle • accès concurren8el à une ressource partagée unique via une « sec8on cri8que » du code – (ex. une imprimante). Demandeur Requête extérieure acquisition Dehors Dedans libération Ingénierie des protocoles 85 Spécifica8on de l’exclusion mutuelle • Sûreté : Au plus un processus est à la fois dans la sec8on cri8que. • Vivacité : Tout processus demandeur finit par entrer en sec8on cri8que. Ingénierie des protocoles 86 Hypothèses • Processus et canaux asynchrones • Pas de fautes • Topologies : anneaux unidirec8onnel avec orienta8on consistante • Au moins deux processus • Un seul ini8ateur • Sec8on cri8que : finie G D D G G D D G G D D Ingénierie des protocoles G 87 Remarque 1. Tout processus exécute sa phase d’ini8alisa8on avant tout autre chose. Ingénierie des protocoles 88 Preuve de correc8on (La preuve est triviale, mais voici une version très détaillée.) Lemme 1 (Sûreté). Jamais plus d’un processus n’est en sec=on cri=que. Preuve. • Une seule créa8on : A l’ini8alisa8on, un seul jeton est créé car il n’y a qu’un seul ini8ateur. • Pas de duplica8on : Chaque processus relaie un message « Jeton » à droite que s’il l’a reçu préalablement de la gauche. Donc, le jeton créé ini8alement reste unique dans le système pendant toute l’exécu8on. Comme un processus ne peut exécuter la sec8on cri8que que s’il dé8ent le jeton, le lemme est vérifié. Ingénierie des protocoles 89 Preuve de correc8on Lemme 2 (Vivacité). Tout demandeur entre en sec=on cri=que en temps fini. Preuve. 1. L’ini8alisa8on dure un temps fini. 2. Le temps d’exécu8on de la sec8on cri8que est fini. 3. Le temps d’acheminement des messages est fini. 4. Le temps de traitement des messages est fini. 5. Toute récep8on d’un jeton est suivie d’un envoi. 6. Le jeton se déplace toujours dans le même sens. On a donc une circula8on de jeton unidirec8onnelle perpétuelle. Ainsi, tout demandeur finit par obtenir le jeton et ainsi finit par exécuter la sec8on cri8que. Ingénierie des protocoles 90 Preuve de correc8on D’après les deux lemmes précédents, nous avons : Théorème 1. L’algorithme 1 résout l’exclusion mutuelle dans un anneau unidirec=onnel. Remarque 2. Si on lève l’une des hypothèses, la preuve ne marche plus ! Ingénierie des protocoles 91 Complexité En nombre de messages et en temps d’exécu8on dans le meilleur et le pire des cas. • Complexité pour un tour de jeton : – n • Si un processus est demandeur en cours d’exécu8on, quel est le nombre de messages générés avant que le processus entre en sec8on cri8que – (pire : n − 1, meilleur : 0) • Temps de service : combien d’autres processus peuvent exécuter la sec8on cri8que avant qu’un processus (demandeur) par8culier ne le fasse – (pire : n − 1, meilleur : 0) • Ra8o nombre de messages / nombre de demandes – (pire : ∞ — aucune demande, meilleur : 1 — tous demandeurs) Ingénierie des protocoles 92 Conclusion sur l’algorithme • Le dernier résultat montre un inconvénient majeur de ce type de solu8on (proac8ve) : les échanges de messages con8nuent même s’il n’y a aucune demande. • Pour régler ce problème, il existe des algorithmes dit « à permission » (réac8ve) Ingénierie des protocoles 93 Deuxième Exemple : Circula8on d’un jeton dans un réseau quelconque Ingénierie des protocoles 94 Spécifica8on La circula=on de jeton est un algorithme à vague Ingénierie des protocoles 95 Algorithme à vague Introduc8on • Dans un système distribué, on a (parfois) besoin de : – Diffuser des informa8ons (à tous les processus) • (Broadcast) m m m m m m Ingénierie des protocoles 97 Introduc8on • Dans un système distribué, on a (parfois) besoin de : – Synchroniser (globalement) les processus • E.g., l’étape i-‐1 est elle finie ? i i i-‐1 i i Ingénierie des protocoles 98 Introduc8on • Dans un systèmes distribué, on a (parfois) besoin de : – Calculer des fonc8ons globales • E.g., quelle est la plus pe8te iden8té ? 23 67 5 43 30 Ingénierie des protocoles 99 Introduc8on • Ces problèmes ont plusieurs points communs • D’où, l’idée de trouver un algorithme général • Les algorithmes à vague Ingénierie des protocoles 100 Défini8on • Un algorithme à vague vérifie les trois propriétés suivantes : – Terminaison – Décision – Dépendance Ingénierie des protocoles 101 Défini8on • Terminaison : Toutes ses exécu8ons (ou vagues) sont finies • Décision : Chacune de ses exécu8ons con8ent au moins un évènement par8culier appelé décision • Dépendance : Chaque évènement de décision est causalement précédé (au sens de Lamport) par au moins un évènement sur chaque processus Ingénierie des protocoles 102 Exemples • Parcours – Largeur – Profondeur (à l’aide d’un jeton) • Propaga8on d’Informa8on avec Retour (PIR) • Applica8ons : snapshot, détec8on de terminaison, calcul d’infimum, etc. Ingénierie des protocoles 103 Instancia8on • Spécificité une (vague de) circula8on de jeton – Décision (de terminaison) • Unique • Par l’ini8ateur – Dépendance • Circula8on : séquen8elle (ordre causal total) Ingénierie des protocoles 104 Instancia8on • Une (vague de) circula8on de jeton – Sûreté : • Il existe au plus un jeton dans le réseau • Au plus une décision est prise (Décision) • Si une décision est prise, alors tous les processus ont été visités par le jeton (Dépendance) – Vivacité • L'exécu8on termine (Terminaison) • L'ini8ateur finit par décider (Décision) Ingénierie des protocoles 105 Remarque • Il existe aussi des algorithmes qui exécutent une infinité de vagues – E.g., circula=on de jeton perpétuelle pour l’exclusion mutuelle Ingénierie des protocoles 106 Hypothèses pour notre circula8on de jeton • Processus et canaux asynchrones • Pas de fautes • Canaux é8quetés de 1 à δp pour tout processus p • Topologies : quelconque (connexe) d’au moins deux nœuds • Mono-‐ini8ateur Ingénierie des protocoles 107 Rappel • Cas plus simple : circula8on dans un réseau en arbre Ingénierie des protocoles 108 Circula8on d’un jeton dans un arbre 1 1 3 1 1 • Vu l’an dernier ! 2 2 2 1 1 Ingénierie des protocoles 109 Circula8on d’un jeton dans un arbre J 1 1 3 1 1 2 2 • L’ini8ateur envoie le jeton J sur le canal 1 2 1 1 Ingénierie des protocoles 110 Circula8on d’un jeton dans un arbre 1 J 1 1 2 1 3 2 • Sur récep8on du canal i, un non-‐ ini8ateur renvoie le jeton sur le canal (i mod δ)+1 2 1 1 Ingénierie des protocoles • Ici δ = 3 • (3 mod 3) + 1 = 1 111 Circula8on d’un jeton dans un arbre 1 1 3 J 1 1 2 2 • Sur récep8on du canal i, un non-‐ ini8ateur renvoie le jeton sur le canal (i mod δ)+1 2 1 1 Ingénierie des protocoles • Ici δ = 3 • (3 mod 3) + 1 = 1 112 Circula8on d’un jeton dans un arbre 1 1 3 1 J 1 2 2 • Sur récep8on du canal i, un non-‐ ini8ateur renvoie le jeton sur le canal (i mod δ)+1 2 1 1 Ingénierie des protocoles • Ici δ = 1 • (1 mod 1) + 1 = 1 113 Circula8on d’un jeton dans un arbre 1 1 3 1 1 2 2 J 1 • Sur récep8on du canal i, un non-‐ ini8ateur renvoie le jeton sur le canal (i mod δ)+1 2 1 Ingénierie des protocoles • Ici δ = 3 • (1 mod 3) + 1 = 2 114 Circula8on d’un jeton dans un arbre 1 1 3 1 1 2 2 • Sur récep8on du canal i, un non-‐ ini8ateur renvoie le jeton sur le canal (i mod δ)+1 2 J 1 1 Ingénierie des protocoles • Ici δ = 1 • (1 mod 1) + 1 = 1 115 Circula8on d’un jeton dans un arbre 1 J 3 1 1 2 1 2 • Sur récep8on du canal i, un non-‐ ini8ateur renvoie le jeton sur le canal (i mod δ)+1 2 1 1 Ingénierie des protocoles • Ici δ = 3 • (2 mod 3) + 1 = 3 116 Circula8on d’un jeton dans un arbre 1 1 J 1 3 1 2 2 • Sur récep8on du canal i, un non-‐ ini8ateur renvoie le jeton sur le canal (i mod δ)+1 2 1 1 Ingénierie des protocoles • Ici δ = 2 • (1 mod 2) + 1 = 2 117 Circula8on d’un jeton dans un arbre 1 1 3 1 1 2 2 2 J 1 1 Ingénierie des protocoles • Sur récep8on du canal i, un non-‐ ini8ateur renvoie le jeton sur le canal (i mod δ)+1 • Ici δ = 2 • (1 mod 2) + 1 = 2 118 Circula8on d’un jeton dans un arbre 1 1 3 1 1 2 2 • Sur récep8on du canal i, un non-‐ ini8ateur renvoie le jeton sur le canal (i mod δ)+1 2 1 1 J Ingénierie des protocoles • Ici δ = 1 • (1 mod 1) + 1 = 1 119 Circula8on d’un jeton dans un arbre 1 J 1 3 1 1 2 2 • Sur récep8on du canal i, un non-‐ ini8ateur renvoie le jeton sur le canal (i mod δ)+1 2 1 1 Ingénierie des protocoles • Ici δ = 2 • (2 mod 2) + 1 = 1 120 Circula8on d’un jeton dans un arbre 1 3 1 1 2 1 1 • Sur récep8on du canal δ, l’ini8ateur décide la terminaison 2 • Ici δ = 2 2 1 Ingénierie des protocoles 121 Circula8on d’un jeton dans un réseau quelconque ? • Est-‐ce que l’algorithme précédent fonc8onne ? NON ! Ingénierie des protocoles 122 Exemple 3 1 1 2 2 1 2 1 1 2 1 1 2 1 2 1 2 2 Ingénierie des protocoles 123 Solu8on • Algorithme de Tarry (1885) • Problème de Labyrinthe • « Ne reprendre l'allée ini>ale qui a conduit à un carrefour pour la première fois que lorsqu'on ne peut pas faire autrement » • Sommets = intersec8ons • Liens = allées entre les intersec8ons des arêtes Ingénierie des protocoles 124 Variables • Pour chaque processus – Un pointeur Père ∈ {T,⊥} ∪ {1…δ} (ini8alisé à NULL) – Un tableau de Booléen Visite[1..δ], ini8alement toutes les cases sont à faux. Ingénierie des protocoles 125 Exemple 3 1 1 1 2 2 1 2 1 1 3 2 1 2 3 1 2 2 1 2 Ingénierie des protocoles 126 Exemple J 1 3 1 1 2 2 1 2 1 1 3 2 1 2 3 1 2 2 1 2 Ingénierie des protocoles 127 Exemple 3 1 1 J 1 2 2 1 2 1 1 3 2 1 2 3 1 2 2 1 2 Ingénierie des protocoles 128 Exemple 3 1 1 1 2 2 1 2 1 1 3 J 2 1 2 3 1 2 2 1 2 Ingénierie des protocoles 129 Exemple 3 1 1 1 2 2 1 2 1 1 3 2 1 2 3 1 J 2 2 1 2 Ingénierie des protocoles 130 Exemple 3 1 1 1 2 2 1 2 1 1 3 2 1 2 3 J 1 2 2 1 2 Ingénierie des protocoles 131 Exemple 3 1 1 1 2 2 1 2 1 1 3 J 2 1 2 3 1 2 2 1 2 Ingénierie des protocoles 132 Exemple 3 1 1 1 2 2 1 2 1 1 3 2 1 2 3 1 J 2 2 1 2 Ingénierie des protocoles 133 Exemple 3 1 1 1 2 2 1 2 1 1 3 2 1 2 3 1 2 2 J 1 2 Ingénierie des protocoles 134 Exemple 3 1 1 1 2 2 1 2 1 1 3 2 1 2 3 1 2 2 1 J 2 Ingénierie des protocoles 135 Exemple 3 1 1 1 2 2 1 2 1 1 3 2 1 2 3 1 J 2 2 1 2 Ingénierie des protocoles 136 Exemple 3 1 1 J 1 2 2 1 2 1 1 3 2 1 2 3 1 2 2 1 2 Ingénierie des protocoles 137 Exemple 3 1 1 J 1 2 2 1 2 1 1 3 2 1 2 3 1 2 2 1 2 Ingénierie des protocoles 138 Exemple 3 1 1 1 2 2 1 2 1 1 3 2 1 2 3 1 J 2 2 1 2 Ingénierie des protocoles 139 Exemple 3 1 1 1 2 2 1 2 1 1 3 2 1 2 3 1 2 2 1 J 2 Ingénierie des protocoles 140 Exemple 3 1 1 1 2 2 1 2 1 1 3 2 1 2 3 1 2 2 J Ingénierie des protocoles 1 2 141 Exemple 3 1 1 1 2 2 1 2 1 1 3 J 2 1 2 3 1 2 2 1 2 Ingénierie des protocoles 142 Exemple 3 1 1 J 1 2 2 1 2 1 1 3 2 1 2 3 1 2 2 1 2 Ingénierie des protocoles 143 Exemple J 1 3 1 1 2 2 1 2 1 1 3 2 1 2 3 1 2 2 1 2 Ingénierie des protocoles 144 Exemple 3 1 1 J 2 1 2 2 1 1 1 3 2 1 2 3 1 2 2 1 2 Ingénierie des protocoles 145 Exemple 3 1 1 J 2 1 2 2 1 1 1 3 2 1 2 3 1 2 2 1 2 Ingénierie des protocoles 146 Exemple 1 1 2 3 Terminé ! 1 2 1 2 1 1 3 2 1 2 3 1 2 2 1 2 Ingénierie des protocoles 147 Conclusion générale • Depuis 40 ans – La plupart des problèmes d’algorithmiques répar8es ont été résolus de manière efficace – En supposant des réseaux sans pannes … Ingénierie des protocoles 148 Challenge actuel • Les réseaux modernes sont à grande-‐échelle et fait de machines hétérogènes et produites en masses à faible coût, e.g. – Internet • (10 milliard de machine connectée d’ici 2016) • Internet des objets – Réseaux sans fils • Communica8on radio : beaucoup de pertes de messages • Crash de machines à cause des ba‚eries limitées ⇒ Forte probabilité de pannes ⇒ Interven8on humain impossible ⇒ Besoin d’algorithmes distribués tolérant les pannes Ingénierie des protocoles 149 Merci de votre a‚en8on ! Ingénierie des protocoles 150