CSC 4509 – Algorithmique et communications des applications réparties

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.

Création et utilisation du projet GitLabEns

Formation des binômes.
Création de votre projet GitLabEns et configurations pour le développement.

Installations et configurations pour l'utilisation du projet `Maven` et pour l'utilisation de GitLabEns

Ce sont les mêmes installations que pour le module CSC4102 et le début du module CSC4509 :

JAVA, Maven, Eclipse, SpotBugs, Checkstyle, etc. : cf. page des installations et configurations du module CSC4102 ;
nous utilisons des assertions JAVA dans notre code, par exemple avec l'instruction « assert invariant(); ». Nous proposons donc d'activer l'utilisation des assertions dans les tests JUnit : dans Eclipse, menu Window > Preferences > JAVA > JUnit puis cochez la case « Add '-ea' to VM arguments when creating a new JUnit launch configuration » (l'option « ea » de la machine virtuelle JAVA signifie « enable assertions ») ;
GitLabEns, chemin de confiance, etc. : cf. énoncé de l'Étape 2 du TP de la séance 1 du module CSC4102.

Création du projet GitLabEns

cette étape est effectuée uniquement par l'un des membres du binôme. Après la création, celui-ci ajoute au projet le second membre.

Voici l'URL du projet GitLabEns, notez le « https » : https://gitlabens.imtbs-tsp.eu/enseignants.csc4509/csc4509-tchat.

Vous vous connectez à la plateforme en utilisant l'authentification Shibboleth repérée par le bouton Shibboleth en bas à droite.

Créez vôtre projet csc4509-tchat par copie avec le bouton Fork. Une fois votre projet créé, configurez-le en suivant les liens Settings et Members :

rendez votre projet « privé » en suivant les liens « Settings > General », puis Expand à la section Permissions, et ensuite, mettez l'attribut Project Visibility à Private. Le non-respect de cette règle revient à vous exposer aux mesures du paragraphe « Fraude » du règlement de scolarité ;
ajoutez votre binôme en tant que Owner et les enseignants du module en tant que Maintainer (au cas où nous ayons besoin d'intervenir dans la branche main) ;
pour recevoir les courriels suite aux push (fonctionnalité email on push), sélectionnez la page Settings/Integrations, cochez la case Push events et parcourez la liste des services disponibles pour sélectionner Emails on push. Dans la page ouverte, cochez les cases Active, Push, Tag push et Send from committer, puis ajoutez les adresses courriels de tous les membres du projet dans le formulaire Recipients. N'oubliez pas de cliquez sur Save changes à la fin.
- Nous (enseignants) demandons à recevoir ces courriels. Par conséquent, ajoutez au moins nos adresses courriels.

Transmettez par courriel aux enseignants l'URL de votre projet GitLabEns ainsi que les nom et prénom des membres du binôme.

Vérification du dépôt du projet

Si ce n'est pas déjà fait, récupérez le dépôt Git de votre projet avec la commande git clone.

Déplacez-vous dans le répertoire du projet et construisez l'application avec la commande « mvn clean install site ».

Adaptez les sources pour le démarrage du projet :

dans le fichier pom.xml, remplacez les informations avec les noms et prénoms de chacun des membres du binôme ;
reconstruisez l'application avec ces nouvelles informations en exécutant la commande « mvn clean install » ;
créez un nouvel instantané du projet en enchaînant les commandes « git status », « git add pom.xml », puis « git commit -m "infos binome" » et ensuite « git push origin main ». Vérifiez que chacun a reçu un courriel pour ce nouvel instantané et que l'intégration continue s'est bien déroulée (dans le site Web de GitLabEns, sélectionnez le projet, puis la page Repository, et ensuite la page Commits). La commande exécutée en intégration continue est contenue dans le fichier .gitlab-ci.yml.

Chargez votre projet dans votre environnement de développement, ici Eclipse :

dans Eclipse, utilisez le menu File / Import / Maven / Existing Maven Projects / Next pour ouvrir l'assistant de création de projet Maven. Puis, Browse et recherche du répertoire de votre projet, etc. ;
sélectionnez le projet et exécutez la commande mvn install : dans le menu contextuel, Run as, etc. Vous devez voir dans la console Eclipse les résultats de la compilation et de l'exécution des tests JUnit (classes de tests TestScenarioStartingFramework, TestScenarioStartingFrameworkWithInterceptorsOnClientSide, TestPointToPointMessage, et TestVectorClock.java) ;
vérifiez l'utilisation de l'outil SpotBugs avec le menu contextuel (bouton droit) SpotBugs / Find Bugs. SpotBugs ne doit pas détecter de problème ;
enfin, vérifiez l'utilisation de l'outil Checkstyle. Choisissez la configuration préparée pour le module CSC4102 (dans l'étape sur la qualité du code). Pour exécuter l'analyse du code par Checkstyle, c'est le menu contextuel Checkstyle / Activate Checkstyle. Checkstyle ne doit pas détecter de problème.

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, ghostwriter, retext, etc.

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 main, puis poser une étiquette dans la branche main.

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 main --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 :

é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 c₂ répond au message d'un client c₁, sans algorithme supplémentaire, il est possible qu'un troisième client c₃ reçoive la réponse de c₂ avant le message de c₁. C'est le rôle de l'algorithme de diffusion causale de rétablir l'ordre causal des messages diffusés : le message de c₁ précède causalement la réponse de c₂ :
- 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.