Mise en œuvre d'algorithmes répartis
La série de TP sur le thème « Mise en œuvre d'algorithmes répartis » utilise comme étude de cas une application de tchat multiclient multiserveur. Le travail que vous effectuez donne lieu à un compte rendu et à du code JAVA construits par morceaux.
Processus de livraison algorithme par algorithme.
Contenu d'une livraison.
La mise en œuvre d'un algorithme est aidée par la réponse à une série de questions. Le rapport contient les réponses à ces questions. Pour éviter les oublis de génération d'un fichier PDF à partir d'un fichier source, et puisque GitLab permet la visualition dans l'interface Web des fichiers au format Markdown, chaque algorithme possède un fichier de questions/réponses dans le répertoire report du projet GitLabEns que vous créerez par fork. Vous trouverez des indications pour la rédaction et la lecture de fichier à ce format dans le fichier readme.md à la racine de votre projet GitLabEns : les fichiers *.md peuvent être lus et écrits dans GitLab (mais beaucoup de commits), dans Eclipse, et dans la console avec emacs, retext, ghostwriter, etc.
Vérification de la qualité du code.
Les voici :
- le projet compile et les tests passent : mvn clean install ;
- SpotBugs ne signale pas de problème grave (autre que de performance) : mvn spotbugs:check ;
- Checkstyle ne signale pas de problème dans le code et dans la documentation Javadoc : mvn checkstyle:check ;
- Javadoc ne signale pas de problème dans la documentation : mvn javadoc:javadoc.
Signalisation du rendu par la pose d'une étiquette.
Voici une proposition de nommage des étiquettes :
- livraisonelection, puis electioncorrection1, etc. pour l'algorithme d'élection,
- livraisondiffusioncausale, puis diffusioncausalecorrection1, etc. pour l'algorithme de diffusion causale,
- livraisonexclusionmutuelle, puis exclusionmutuellecorrection1, etc. pour l'algorithme d'exclusion mutuelle,
- livraisondetectionterminaison, puis detectionterminaisoncorrection1, etc. pour l'algorithme de détection de terminaison.
Pour lister les étiquettes, ajouter une nouvelle étiquette, et pousser sur GitLabEns les étiquettes :
Liste des tâches et des algorithmes (jusqu'à la fin du module)
-
création du projet :
tous les travaux sur ce thème sont effectués en binôme dans le
cadre d'un projet GitLabEns :
- cf. page création du projet ;
-
étude de l'ossature de départ de l'application de tchat
multiclient multiserveur :
le projet utilise une ossature de départ de
l'application ; la page référencée ci-dessous est en
quelque sorte le manuel de référence du code fourni au début
du projet :
- cf. page étude de l'ossature de départ ;
-
mise en œuvre d'un algorithme d'élection :
certains algorithmes requièrent qu'un processus possède un
rôle particulier ; ce processus peut être connu à la
suite d'une élection (c'est plus pratique que de le définir
par configuration statique). Par exemple, pour une exclusion
mutuelle, c'est le processus gagnant qui génère le
jeton. Autre exemple : c'est le processus gagnant qui lance
périodiquement une vague pour détecter la terminaison :
- cf. fichier report/algo_election.md dans le dépôt Git du projet ;
-
mise en œuvre d'un algorithme de diffusion causale :
les messages de tchat sont diffusés par les serveurs. Un
client reçoit tous les messages de tchat. Mais, si un
client c2 répond au message d'un
client c1, sans algorithme
supplémentaire, il est possible qu'un troisième
client c3 reçoive la réponse
de c2 avant le message
de c1. C'est le rôle de l'algorithme
de diffusion causale de rétablir l'ordre causal des messages
diffusés : le message de c1
précède causalement la réponse
de c2 :
- cf. fichier report/algo_diffusion_causale.md dans le dépôt Git du projet ;
-
mise en œuvre d'un algorithme d'exclusion mutuelle :
à un instant donné, un des serveurs de tchat est responsable
de l'enregistrement des messages de tchat (dans une base de
données ou dans un fichier) et chaque serveur peut demander à
avoir ce droit. La base de données ou le fichier est accédé en
exclusion mutuelle :
- cf. fichier report/algo_exclusion_mutuelle.md dans le dépôt Git du projet ;
-
mise en œuvre d'un algorithme de détection de terminaison
puis d'un algorithme de terminaison :
lorsqu'il n'y a plus de client et que les serveurs n'ont plus
rien à faire, les serveurs peuvent être terminés. C'est le
processus élu qui détecte la terminaison et termine tous les
serveurs de l'application répartie :
- cf. fichier report/algo_detection_et_terminaison.md dans le dépôt Git du projet.
