Configuration expérimentale

L’application de charge que nous avons développée pour le service de désignation a un comportement cyclique qui consiste à construire un arbre de nommage de profondeur 100, à résoudre des noms à différentes hauteurs dans l’arbre, puis à détruire l’arbre. Puisque l’arbre est créé de manière déterministe, l’application de charge est capable de vérifier en ligne la validité des résultats fournis par le SUT. Lorsqu’un élément de la charge détecte une anomalie dans le fonctionnement du SUT, par exemple une

résolution de nom qui ne renvoie pas la bonne référence1_{, elle signale aux compo-} 1_{Le modèle à objets deCORBAn’autorise pas le test d’égalité entre références objets. Nous ne pouvons}

donc pas détecter des réponses invalides du service de désignation en effectuant une simple comparaison entre la référence liée et celle renvoyée par leSUT. Afin de contourner ce problème, nous utilisons des objets contenant des identifiants uniques, et effectuons la vérification d’égalité sur cet identifiant.

database injecteur

requete resolve() corrompue charge1 charge2

bind(), resolve(), unbind()

service

cible

démarrer _controlleur

FIG. 3.2 –Configuration des expériences ciblant le service de désignation

sants d’observation qu’une défaillance applicative s’est produite. De la même façon, lorsqu’elle reçoit une exception provenant du SUT, elle en informe les composants d’observation afin que cet événement soit enregistré, avec sa date d’occurrence. La configuration expérimentale pour nos expériences ciblant le service de désignation est illustrée dans la figure3.2.

Dans nos campagnes d’injection de faute, chaque expérience correspond à l’injection d’une seule faute. Un processus de contrôle démarre le SUT et obtient sa référence objet. Il démarre alors les processus de charge, en leur fournissant la référence du

SUT. Après un certain laps de temps (distribution aléatoire autour de 20 secondes), le

composant injecteur envoie une requête corrompue au service, en lui demandant de résoudre un nom qui a été précédemment lié. L’injecteur attend alors la réponse du service, et vérifie que la réponse est correcte. Si aucune réponse n’arrive dans un délai de 30 secondes, un mode ConnectionHang est signalé aux processus d’observation. À la fin de l’expérience, les processus d’observation vérifient que la machine cible fonctionne correctement (en cherchant à exécuter une commande sur la machine), que le SUT répond encore aux requêtes des clients, et que les processus de charge fonctionnent encore. Chaque expérience dure ainsi environ deux minutes.

L’injecteur de faute dans ces expériences est un programme qui prend en paramètre la référence objet du SUTet un entier identifiant la position de la faute à injecter. Le comportement de l’injecteur est le suivant :

1. établir une connexion réseau avec leSUT;

2. vérifier que leSUTjoue bien le rôle de service de désignation, en lui envoyant une

requête _is_a pour l’interface IDL:omg.org/CosNaming/NamingContext:1.02_;

3. lier le nom ABCDE.FGH au contexte racine du service de désignation (opération rebind) ;

2_{Cette méthode _is_a est généralement invoquée de manière transparente par un courtier à l’occasion}

de la première utilisation d’un IOR. Elle permet au courtier d’assurer que le type de l’objet invoqué est compatible avec celui souhaité par le client.

4. demander au service de résoudre le nom ABCDE.FGH (opération resolve). C’est ce message qui subit une corruption.

5. vérifier que la référence renvoyée par leSUTjoue le rôle de service de désigna-

tion, c’est à dire qu’elle identifie la même interface que celle liée à l’étape 3. Nous avons injecté deux types de faute : des inversions de bits et des mises à zéro de deux octets successifs dans le message IIOP. Ces types d’erreurs ont été choisis puisqu’ils sont parmi les plus fréquemment observés dans l’étude de Stone et Par- tridge [Stone & Partridge 2000] que nous avons déjà mentionnée.

zB — Taille d’une requêteCORBAen fonction du courtier

On pourrait supposer qu’une même requêteCORBA, pour la même opération sur la même interface, ait la même représentation au niveau de la couche transport, indépendamment du courtier utilisé. En pratique il n’en est rien : la taille d’une requêteCORBA, lorsqu’elle est transmise à la couche transport, varie en fonction des courtiers utilisés côté client et côté serveur. Pour comprendre pourquoi, considérons les éléments qui composent une requête

CORBA:

• un en-tête, qui contient la signature GIOP, le numéro de version du protocole, et le type GIOP du message (RequestMessage, ReplyMessage, ErrorMessage, etc.) ; • la taille de la requête en nombre d’octets, codée sur 32 bits ;

• l’identifiant de la requête, un entier non signé codé sur 32 bits ;

• le « service context », qui permet au courtier client de transmettre des informations concernant le contexte dans lequel s’effectue la requête ;

• la clé de l’objet invoqué (l’« object key ») ; • le nom de l’opération invoquée ;

• les arguments de la requête.

L’en-tête GIOP et la taille du message sont de longueur fixe, mais la taille des autres éléments est variable. Pour une « même » requête, le nom de l’opération et les arguments ont une longueur fixe. Le contenu du service context est déterminé par le courtier côté client. La taille de la clé de l’objet invoqué dépend du courtier qui héberge cet objet côté serveur.

Lorsque plusieurs servants partagent la même capsule (par exemple, le même processus Unix), la clé (une séquence d’octets dont le format n’est connu que du courtier qui la génère) permet d’identifier à quel servant est destinée la requête. La clé d’un objet est générée par le courtier serveur, et fait partie de toute IOR le désignant. Tous les courtiers ne génèrent pas les clés de la même façon, et en particulier les clés n’ont pas toutes la même longueur. En conséquence, la « même » requête sur le même objet aura une longueur qui varie en fonction du courtier qui héberge cet objet.