sujet - Verimag

TP 2 - Élection - Broadcast
Quelques compléments sur Sinalgo
Envoi de messages et identifiant de noeud
Dans le TP 1, un processus envoyait un message à l’ensemble de ses voisins à l’aide de la fonction
broadcast(Message M). Il est également possible de n’envoyer un message qu’à un seul voisin à
l’aide de la fonction send(Message M, Node n) héritée de la classe nœud. Si le nœud n n’est pas un
voisin direct du nœud courant, une exception NoConnectionException est levée.
On peut obtenir les références Node des nœuds voisins à l’aide du champ outgoingConnections, qui
est une collection d’objets Edge (une arête du graphe). Edge possède l’attribut endNode qui
correspond au nœud cible de l’arête.
Par exemple, un broadcast d’un Message m à l’ensemble des voisins peut être écrit :
for (Edge e : outgoingConnections) {
Node dest = e.endNode;
send(m, dest);
}
On touche ici à une limite du modèle de simulation de Sinalgo. Un noeud peut obtenir une reference
sur ses noeuds voisins (et plus généralement, sur n’importe quel noeud du système), et utiliser cette
reference pour modifier l’état de ce noeud. Toutefois, il faut bien comprendre que dans les
algorithmes que l’on cherche à simuler, le seul moyen de communiquer avec un noeud est l’envoi
de message. Autrement dit, les references Node ne doivent être utilisées que pour identifier un
noeud voisin lors d’un envoi de message. On peut voir les références Node comme des
identifiants de nœud, mais on s’interdit d’appeler leurs méthodes ou d’accéder à leurs attributs au
cours d’une simulation.
Un problème similaire se pose avec les Messages. Lorsqu’un message est transmis, c’est une
reference sur un objet qui est transmise. En réalité, lors d’un envoi de message sur un réseau, le
message est copié. C’est pourquoi Sinalgo force à definir une methode clone sur les messages.
Remarque : attention à ne pas confondre les identifiants de noeuds que l’on utilise comme port de
communication vers les noeuds voisins via la function send, avec les idenfiants uniques (UIN)
génerés dans certains algorithms.
Rappel - Interface utilisateur
On peut très facilement rajouter des commandes dans le menu contextuel associé aux nœuds (clic
droit sur un nœud). Il suffit de rajouter une méthode annotée dans la classe Node. L’annotation
définit le texte associé à la méthode dans le menu contextuel. Par exemple :
@NodePopupMethod(menuText="broadcast")
public void broadcastMenu() {
setColor(Color.BLUE);
broadcast(new LcrMessage(this.uin));

}
On peut également rajouter des boutons dans le menu Project Control, en rajoutant une méthode
annotée à la classe CustomGlobal. Par exemple, pour réinitialiser tous les nœuds, on peut définir la
méthode suivante.
@AbstractCustomGlobal.CustomButton(buttonText="Reset", toolTipText="Reset default color")
public void initButton() {
for (Node n : Tools.getNodeList()) n.init();
}
Arbre de recouvrement dans un graphe connecté quelconque
Dans la suite, on suppose que G = (V, E) est un graphe non-orienté connexe. A partir d’un nœud
donné, on veut :
•transmettre une information à tous les nœuds du graphe (broadcast).
•construire un arbre couvrant.
L’algorithme se base sur une « vague ». Chaque nœud possède un champ parent qui identifie le
nœud de son père (initialement null). L’initiateur de la vague transmet un message à tous ses
voisins. Lorsqu’un processus reçoit un message, il met à jour parent avec l’identifiant (Node) de
l’émetteur du premier message reçu, puis retransmet le message à ses voisins autres que son père.
Il ignore les autres messages reçus.
1. Ecrire le pseudo-code de cet algorithme.
2. Implanter l’algorithme dans un projet ast (Asynchronous Spanning Tree). L’utilisateur lance
l’algorithme à l’aide du menu contextuel associé à un nœud. Un bouton global « reset »
permet de réinitialiser les nœuds.
3. Pour tester l’algorithme, vous tracerez les liens manuellement, et utiliserez une distribution
initiale des nœuds aléatoire.
./sinalgo –project ast -gen 10 ast:Node Random
4. Quel est le nombre total de messages envoyés lors d’une exécution de l’algorithme ?
5. Montrer que sur une topologie donnée, l’algorithme peut générer différents arbres de
recouvrement en fonction de l’ordre d’arrivée des messages.
6. Enrichir l’algorithme avec des accusés de réception qui permettent à l’émetteur initial de
savoir que tous les nœuds ont bien reçu son message.
7. Quel est le nombre total de messages envoyés ?
8. Quelle est la durée d’exécution de l’algorithme ? comparer avec l’algorithme ast.
Indication : on pourra utiliser comme paramètres le nombre de noeuds et/ou la le diamètre
du graphe.
9. Comment modifier l’algorithme astack pour que l’émetteur connaisse le nombre de nœuds
dans le graphe ?

Anneau bidirectionnel
L’algorithme de Hirschberg-Sinclair (HS)
L’algorithme de Hirschberg-Sinclair (HS) est un algorithme d’élection de leader dans un anneau
bidirectionnel. Comme pour l’algorithme LCR, chaque processus possède un identifiant unique et le
processus avec le plus grand UIN se proclame leader. Contrairement à LCR, les communications
sont bidirectionnelles. C’est à dire qu’un processus Pi de l’anneau peut communiquer avec ses
voisins Pi+1 et Pi−1 . De plus, un processus n’envoie pas son identifiant à travers tous les processus de
l’anneau. Il l’envoie de telle sorte que l’UIN parcourt seulement quelques processus voisins dans
une direction, fait demi-tour, et retourne à son point de départ. Il recommence en augmentant la
distance parcourue à chaque fois.
On donne maintenant une description informelle de l’algorithme :
Chaque processus fonctionne en phases identifiées par une variable l = 0, 1, 2.... Lors de la phase 1,
chaque Pi envoie son UIN ui dans les deux directions. Les ui doivent parcourir une distance 2l et
revenir à leur origine. Si les deux identifiants ui reviennent à Pi , le processus Pi passe à la phase
suivante. Toutefois, les deux identifiants ne reviennent pas forcément jusqu’à Pi :
•Lorsqu’un identifiant ui se déplace en s’éloignant de Pi, chaque processus Pj parcouru
compare ui à son propre identifiant uj . Si ui < uj , alors Pj supprime le message. Si ui > uj ,
alors Pj retransmet le message. Si ui = uj , cela signifie que ui a parcouru tout l’anneau sans
faire demi-tour et qu’il est le plus grand identifiant, donc Pi se proclame leader.
•Lorsqu’un identifiant ui se déplace en retournant vers Pi , les processus parcourus se
contentent de le retransmettre.
1. Téléchargez le fichier hs.tar qui contient un squelette du projet à compléter. En particulier :
•Il définit le modele de connectivité projects.ast.models.connectivityModels.BiRing qui
permet de générer les liens de communication correspondant à une topologie en anneau
directionnel.
•Il définit le type HSMessage et le modèle de connectivité BiRing.
On rappelle la commande pour exécuter le projet :
./sinalgo –project hs -gen 10 hs:Node Circle hs :BiRing
2. Donnez le pseudo-code de cet algorithme dans le langage utilisé en cours.
3. Implantez l’algorithme. Indication : les messages transmis contiendront les valeurs UIN, dir,
hopcount, et sender, l’adresse du processus émetteur. UIN est un identifiant, dir ∈ {out, in}
indique la direction du message (éloignement ou retour par rapport à l’émetteur), et
hopcount compte le nombre de processus restant à parcourir.
4. Montrez que le nombre total de message envoyé lors d’une execution de l’algorithme est
O(n.log(n)).
[Facultatif] Modèle de connectivité ConnectedGraph
Plutôt que de tracer des graphes à la main, il est possible de les générer automatiquement en
programmant un nouveau modele de connectivité. En vous inspirant des modèles BiRing et
UniRing, définissez une classe ConnectedGraph qui génère un graphe aléatoire bidirectionnel et
connecté.

Compte rendu
1. Une archive contenant votre travail est à envoyer à [email protected] avec comme
objet « [TP-ALR] nom des binômes » au plus tard le jeudi 24 mars. Un email de
confirmation sera envoyé dans les 24h, aucun CR ne sera corrigé passé cette date.
2. L’archive doit être de le forme “nomA_nomB.tar.gz” et se décompresser vers un répertoire
nomA_nomB. Ce répertoire contiendra un ficher rapport_nomA_nomB.pdf, éventuellement
un fichier README, et un répertoire sources qui contient les sources java des trois projets.
3. Dans le rapport, faites apparaître le code de la fonction handleMessage.