Aspects du protocole inter-répliques

Les lignes 6-9 et 11 sont des préoccupations transversales que nous encapsulons dans des aspects comme décrit ci-dessous.

5.3.3.1 Aspects côté serveur primaire

La gestion de la propagation de la requête reçue par le serveur primaire vers le serveur se- condaire est également une préoccupation transversale. Elle est encapsulée dans un aspect

– ACheckPoint.forwardRequest : transmet la requête reçue par le primaire au serveur se- condaire.

– ACheckPoint.buildCheckPoint : construit un point de reprise à partir de l’état de l’appli- cation après l’exécution du service et une copie de la réponse obtenue. Une fois le point de reprise construit, il est envoyé au serveur secondaire.

La chaîne d’octets contenue dans chaque message délivré au serveur directement utilisée pour invoquer les commandes sur le serveur en projetant cette chaîne sur le format de requête attendu. Les informations supplémentaires contenues dans le message peuvent compromettre cette interprétation. Deux greffons ANumbering.remove et AIdentifier.remove sont chargés de supprimer le numéro de séquence de la requête et l’identifiant de client et d’insérer à nouveau le numéro de séquence de la requête avant l’envoi de la réponse.

L’aspect ANumbering utilisé côté client est réutilisé côté serveur. Il s’agit plus précisément de réutiliser le greffon ANumbering.remove qui supprime le numéro de séquence de la requête arrivant du côté du serveur avant que la chaîne d’octets reçue ne soit interprétée pour exécuter le service correspondant.

À l’aspect AIdentifier nous ajoutons alors un greffon nommé AIdentifier.remove qui prend en charge la tâche suivante :

– AIdentifier.remove : supprime l’identifiant du client de la requête reçue.

Du coté serveur primaire et secondaire un aspect nommé AServeurMode prend en charge les préoccupations liées à l’initialisation du serveur. Il contient un greffon nommé AServeur- Mode.init dont la tâche est la suivante :

– AServeurMode.init : lit les informations de configuration dans un fichier et initialise une variable correspondant au mode.

Dans cette section le mode du serveur est initialisé à "Duplex primaire".

1 variable du protocole :

2 mode =single

3

4 Boucle primaire single {

5 reception de la requete

6 si ( duplication ){ renvoyer le resultat stocke }

7 sinon { retirer identifiant de requete

8 retirer identifiant client

9 calcul du resulat

10 envoi de la reponse }

11 }

Listing 5.4 – Algorithme du serveur en mode single

5.3.3.2 Aspects côté serveur secondaire

Plusieurs préoccupations transversales sont dispersées dans le comportement du serveur en mode secondaire. Elles concernent essentiellement la gestion de la synchronisation entre le serveur primaire et secondaire.

En ce qui concerne la gestion de la synchronisation entre le serveur primaire et le serveur secondaire, à l’arrivée d’un message provenant du primaire deux cas sont possibles :

– il s’agit de la propagation de la requête sans le résultat associé. – il s’agit de la propagation d’un point de reprise.

La gestion de ces deux comportements relatifs à la synchronisation est encapsulé dans un aspect appelé ACheckPoint. Il s’agit du même aspect utilisé dans le cadre du serveur primaire. Nous ajoutons deux greffons à ce dernier ACheckPoint.putInCache et ACheckPoint.updateCache. Ces deux greffons ont les rôles suivants :

– ACheckPoint.putInCache : stocke la requête reçue dans une structure de données. – ACheckPoint.updateCache : stocke le point de reprise dans une structure de données. – ACheckPoint.updateState : met à jour l’état du serveur grâce aux informations conte-

nues dans le point de reprise.

La structure de données considérée est décrite dans la figure5.4. Il s’agit d’un tableau. Ce tableau contient trois colonnes qui servent à stocker les informations concernant des requêtes reçues :

1. l’identifiant du client qui a envoyé la requête, 2. le numéro de séquence de la requête,

3. la réponse associée à la requête.

Le greffon ACheckPoint.putInCache est exécuté dans le cas où il s’agit de la propagation de la requête et non du point de reprise. Dans ce cas, seules les colonnes correspondant à l’iden- tifiant du client et à l’identifiant de la requête sont remplies après lors de la création d’une nouvelle ligne dans la table.

Le greffon ACheckPoint.updateCache est appliqué aussi lorsqu’il s’agit de la propagation d’un point de reprise. Dans ce cas, seule la colonne résultat est mise à jour et les différents élé- ments composant l’état du serveur sont mis à jour.

5.3.3.3 Aspects côté serveur en mode single

Plusieurs préoccupations transversales composent le comportement du secondaire bascu- lant en mode primaire (crash du serveur primaire).

Les greffons de suppression d’identifiant client et de numéro de séquence de requête ont déjà été présentés dans le cadre du serveur primaire et secondaire. Ces greffons, ANumbe- ring.insert et ANumbering.remove sont réutilisés ici. Ils sont appliqués dans le deuxième cas de figure abordé ci-dessus.

Dans le premier cas de figure lorsque la requête a déjà été exécutée, la récupération du ré- sultat correspondant et son envoi sont des préoccupations transversales. Ces dernières sont encapsulées dans un aspect appelé ACheckDuplicate contenant un greffon nommé ACheckDu- plicate.check. Le rôle de ce greffon est le suivant :

– ACheckDuplicate.reply : gère le cas où la requête est dupliquée. Si la requête est dupli- quée et si le résultat de la requête est retrouvé dans le cache, alors la méthode send est invoquée avec en paramètre le résultat récupéré dans le cache. Si la réponse n’est pas dans le cache, alors cette requête doit être traitée.