sujet - Verimag

TP 3 – Vagues multiples, plus court chemin
Si vous n’aviez pas réussi à terminer le TP 2, une solution pour AstAck est disponible sur la page
des TP.
Vagues dans un graphe connecté quelconque – Applications
Dans cette partie, on met en application l’algorithme AstAck du TP2 pour résoudre un problème de
consensus simple.
On suppose que chaque nœud est initialement vert ou bleu. Les processus doivent se coordonner
pour choisir une même couleur pour tous, qui correspond à la couleur initiale majoritaire. On veut
de plus qu’un processus ne change au plus qu’une fois sa couleur.
On peut résoudre ce problème à l’aide de l’algorithme suivant. Chaque processus diffuse son
identifiant et sa couleur aux autres processus à l’aide de l’algorithme AstAck. Lorsqu’il connaît la
couleur des autres processus, il peut choisir sa couleur finale. Il s’agit donc d’un algorithme à vague
multiple dans lequel chaque processus crée une vague.
Indications :
•Dans l’algorithme AstAck, chaque processus maintient l’adresse de son père dans une
variable parent. Ici chaque processus initie une vague, qui va créer un arbre de
recouvrement. Il faut donc mémoriser l’adresse d’un père pour chacun de ces arbres.
Comme on ne connaît pas le nombre de nœuds du graphe, on utilisera une table
d’association :
Map<Node, Node> m = new HashMap<Node, Node>()
La table m est définie pour chaque processus et associe à un nœud n1, initiateur de vague,
un nœud n2 qui correspond au père dans l’arbre de recouvrement qui permet de remonter à
n1.
•Un processus utilise deux compteurs qui permettent de compter les nombres de couleurs.
Pour savoir quand il a reçu toutes les couleurs, il doit connaître le nombre de processus dans
le graphe. Il peut obtenir cette information via les accusés de réception de l’algorithme
AstAck (cf. TP 2).
Remarque : on peut également résoudre le problème à l’aide d’une méthode un peu différente.
Chaque processus ne diffuse que son identifiant via AstAck, et récupère les couleurs dans les
accusés de réception.
1. Implanter cet algorithme dans un nouveau projet (consensus)
2. Pourrait-on utiliser l’algorithme Ast plutôt que AstAck ?
3. Quel est le nombre total de messages envoyés (en fonction des nombres de nœuds et
d’arêtes du graphe)?
4. Quel est le temps d’exécution ?
Une autre méthode pour résoudre le problème est d’élire un leader (également à l’aide d’une vague
multiple), puis d’utiliser ce leader comme coordinateur.

1. Détaillez l’algorithme
2. Quel est le nombre de messages envoyés ?
3. Quel est le temps d’exécution
4. Quel est l’avantage de cette méthode sur la précédente
5. [facultatif] Implanter l’algorithme dans un nouveau projet (consensusleader)
Plus court chemin
L’algorithme Ast du TP2 construit un arbre de recouvrement qui n’est pas forcément minimal. En
fonction de l’ordre dans lequel les messages sont reçus, il peut exister des chemins dans l’arbre
entre un processus et la racine qui ne sont pas les plus courts.
Il est possible de modifier l’algorithme Ast pour garantir que le chemin entre un nœud et la racine
de l’arbre soit toujours minimal (essayer de réfléchir à une solution avant de lire la suite !).
La solution est la suivante (algorithme AstMin). Dans l’algorithme Ast, un processus n’accepte que
le premier message d’un père potentiel, et ignore tous les autres. Ce faisant, il élimine la possibilité
de connaître un chemin plus court vers le père.
Pour palier à ce problème, les messages contiennent la longueur du plus court chemin connu entre
un nœud et la racine, et chaque processus maintient sa distance entre lui et la racine. Chaque fois
qu’un processus reçoit un message, si ce message contient une distance plus courte que celle qu’il
connaît, il met à jour son père et la distance. Mais attention, il faut également qu’il renvoie sa
nouvelle distance à ses voisins.
Remarque : Un algorithme similaire est utilisé dans le protocole RIP pour le routage IP.
1. Définir l’algorithme dans le pseudo langage du cours. Evaluer le nombre de messages
envoyés.
2. Implanter cet algorithme dans un projet AstMin.
3. Observer son exécution.
4. L’émetteur initial ne sait pas quand l’algorithme se termine. Proposez une méthode pour que
l’émetteur soit informé de la terminaison de l’algorithme et écrire le pseudo code
correspondant.
5. [facultatif] Implanter l’algorithme dans un nouveau projet (astminack).
Compte rendu
1. Compte rendu au format pdf ou txt à envoyer à [email protected] avec comme
objet « [TP-ALR] nom des binômes » au plus tard le mercredi 25 avril. Un email de
confirmation sera envoyé dans les 24h, aucun CR ne sera corrigé passé cette date.
2. En pièce jointe, ajouter les fichier tar.gz correspondant aux différents algorithmes.
3. Dans le CR, faites apparaître au minimum le code de la fonction handleMessage (et des
fonctions qu’elle utilise).