CSC4509 – Algorithmique et communications des applications réparties

Portail informatique

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.

Nous vous invitons à livrer un algorithme dès que vous en avez terminé la mise en œuvre et le rapport.

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 et retext.

Vérification de la qualité du code.

Les vérifications sont effectuées en intégration continue. Donc, avant de pousser des modifications du code sur votre dépôt GitLabEns, faites les vérifications de la qualité du code par vous-même dans une console avec des commandes Maven.

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.

Pour indiquer que votre mise en œuvre est prête pour évaluation, veuillez fusionner votre branche dans la branche master, puis poser une étiquette dans la branche master.

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 :

$ git tag -l $ git tag -a monétiquette $ git push origin master --tags
Voir aussi la page « Trucs et astuces Git »

Liste des tâches et des algorithmes (jusqu'à la fin du module)

Voici la liste des tâches et des algorithmes ; veuillez vous référer au tableau de bord de la page d'accueil pour l'agenda des TP et des dates de livraison proposées :
  1. création du projet : tous les travaux sur ce thème sont effectués en binôme dans le cadre d'un projet GitLabEns :
  2. é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 :
  3. 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 ;
  4. 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 ;
  5. 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 ;
  6. 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.

 


$Date: 2021-05-28 11:27:12 +0200 (ven. 28 mai 2021) $