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 GitLabEnse

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

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

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 ») ;
GitLabEnse, chemin de confiance, etc. : cf. énoncé de l'Étape 2 du TP de la séance 1 du module CSC4102.

Création du projet GitLabEnse

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 GitLabEnse, notez le « https » : https://gitlabense.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 :

si ce n'est pas déjà fait, dans le menu du projet à gauche, suivez l'entrée « Settings > General », puis ouvrez la section « Visibility, project features, permissions ». Rendez votre projet « privé » : Project Visibility > Private, et à la fin de cette section, Save changes. 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, puis la page 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 GitLabEnse ainsi que les noms et prénoms 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 GitLabEnse, 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 1.c du TP de la séance 8 sur la qualité du code : par exemple avec la feuille de style sun_checks_adapted_to_tsp_csc_v_10.2+.xml). 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.

L'exécution de tous les tests ou d'une seule classe de test sont effectuées dans la console avec les deux commandes qui suivent :

mvn test
p.ex. la classe de tests TestScenarioStartingFramework,
mvn test -Dtest=chat.startingframework.TestScenarioStartingFramework

La vérification de la qualité du code avec Checkstyle (partie documentation) et Spotbugs (détection de bugs) dans la console est effectuée par les deux commandes qui suivent :

mvn checkstyle:check
mvn spotbugs:check

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 GitLabEnse. Pour l'utilisation (écriture et lecture) des fichiers Markdown, reportez-vous à la page des installations et configurations du module CSC4102.

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 GitLabEnse, 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,
etc.

Pour lister les étiquettes, ajouter une nouvelle étiquette, et pousser sur GitLabEnse 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₂.
Observez que l'utilisation du protocole TCP avec une programmation mono-thread des serveurs, la propriété causale est respectée.
Mais, si nous décidons un jour de remplacer le FullDuplexMsgWorker du squelette pour utiliser le protocole UDP ou si nous décidons de rendre les serveurs « fortement » multi-threadés, alors nous devons rétablir la propriété causale par algorithme :
- 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 (notez que, dans le temps imparti, nous ne ferons effectivement pas d'enregistrement des messages) :
- 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.