Analyse des diagnostics d’erreur

Nous analysons maintenant plus en détail les résultats des expériences où l’erreur injectée a été détectée. Cette détection est rapportée par l’intergiciel côté client via la levée d’une exception CORBA. La qualité de ce diagnostic est déterminante pour la sûreté de fonctionnement du système, puisqu’elle détermine la pertinence des méca- nismes de recouvrement d’erreur qui peuvent être mis en œuvre au niveau applicatif par le client.

TRANSIENT une erreur de communication transitoire s’est produite COMM_FAILURE une erreur non-transitoire de communication s’est produite

(généralement provoquée par l’arrêt inopiné du serveur) BAD_OPERATION l’opération désignée par la requête (le nom de la méthode)

est invalide

OBJECT_NOT_EXIST l’objet désigné par la requête n’existe pas

OBJ_ADAPTER l’adaptateur d’objets a rencontré une erreur (typiquement ceci indique que la clé objet contenue dans la requête ne correspond à aucun adaptateur d’objets)

INV_OBJREF la référence objet est mal formée (par exemple le Repository- ID est invalide)

MARSHAL une erreur est survenue lors de l’emballage ou du déballage des données vers ou depuis le format CDR

NO_MEMORY l’objet serveur ne dispose pas de suffisamment de mémoire pour accomplir la requête

INTERNAL une erreur interne au courtier s’est produite

UNKNOWN une erreur inconnue (non diagnostiquée par le courtier) s’est produite du côté serveur

FIG. 3.4 –Exceptions CORBAlevées au niveau intergiciel

La figure 3.4 présente les différentes exceptionsCORBA qui peuvent être levées par l’intergiciel. Il s’agit d’exceptions dites de type système, dont la sémantique est définie par la norme CORBA. La figure 3.5page suivante donne la répartition par cible des exceptionsCORBAobservées, pour les expériences avec détection.

Une première information apportée par cette figure est la proportion d’exceptions de type INTERNAL et UNKNOWN levées par les différents candidats. Ces exceptions sont « mauvaises » dans le sens où elles ne fournissent pas d’information utile pour le diagnostic de l’erreur, et ne guident pas le niveau applicatif dans un éventuel choix d’action de recouvrement. Le candidat Sun JDK est peu robuste d’après ce critère.

TAO ORBacus omniORB MICO ORBit Sun JDK IBM JDK somme = 100% 0 10 20 30 40 50 60 COMM_FAILURE BAD_OPERATION MARSHAL OBJECT_NOT_EXIST OBJ_ADAPTER INV_OBJREF NO_MEMORY INTERNAL UNKNOWN

FIG. 3.5 –Distribution des exceptions par cible, expériences avec détection.

Expériences d’inversion de bits pour le service de désignation.

La proportion d’exceptions BAD_OPERATION varie peu entre les candidats. Ceci s’explique si l’on considère que la partie du message IIOP qui identifie l’opération à invoquer doit forcément être décodée par le courtier ; il n’est donc pas surprenant d’observer que le pouvoir de détection d’erreurs pour cette zone est proche pour des implémentations différentes.

Les exceptions OBJECT_NOT_EXIST, OBJ_ADAPTER et INV_OBJREF signalent la même situation de corruption de la clé objet. La proportion de ces exceptions n’est pas équi- valente entre implémentations, même en cumulant ces trois exceptions pour chaque implémentation. La différence s’explique par le fait que omniORB et MICO génèrent des clés d’objet bien plus courtes que les autres courtiers, et donc que la proportion de la requête qui représente la référence objet est plus faible pour eux que pour les autres cibles.

Influence de la position de la faute

La figure3.6page ci-contre présente les diagnostics d’erreur observés en fonction de la position dans le message IIOP où la faute a été injectée. Cette figure correspond aux expériences d’inversion de bits visant le service de désignation, toutes cibles confondues. On constate que les corruptions qui affectent les premiers 32 bits du mes- sage sont détectées par leSUTet toujours signalées (quelle que soit l’implémentation visée) par une exception de type COMM_FAILURE. Cette observation s’explique par le fait que les requêtes CORBA commencent par quatre octets « magiques » (les carac- tères ’G’, ’I’, ’O’, ’P’encodés enASCII), dont la corruption peut facilement être détectée par l’intergiciel.

paramètres de l’opération requesting_principal object−key operation... 32 64 0 #\G #\I #\O #\P 16 8 message−length 48 en−tête GIOP−version byte−order message−type service−context... response−expected? OBJECT_NOT_EXIST COMM_FAILURE MARSHAL ConnectionHang BAD_OPERATION autre exception

FIG. 3.6 –Diagnostics d’erreur en fonction de la position de la faute

Les exceptions de type BAD_OPERATION (qui indiquent que le nom de l’opération invo- quée est invalide) sont levées principalement lorsque la corruption touche la partie de l’en-tête qui identifie l’opération à invoquer. De la même manière, les exceptions de type OBJECT_NOT_EXIST et INV_OBJREF sont levées essentiellement lorsque la corrup- tion touche la portion du message qui identifie l’objet à invoquer.

Des exceptions de type NO_MEMORY sont levées par le candidat ORBacus lorsque l’inversion de bits touche à la longueur annoncée du message. L’inversion de bits rend la longueur annoncée du message très grande4_{. Le courtier cherche à allouer un tam-}

pon mémoire de grande taille pour contenir le message, et le système d’exploitation informe le courtier qu’il ne peut pas allouer autant de mémoire ; le service renvoie cette information au client par une exception NO_MEMORY.

Les exceptions de type MARSHAL sont surtout levées lorsque les paramètres du message (ici un nom, qui est composé d’une séquence de chaînes de caractères) sont corrom- pus.

Qualité du diagnostic pour recouvrement d’erreur

Analysons maintenant ces résultats du point de vue des mécanismes de recouvrement d’erreur qui peuvent être mis en œuvre par les clients. Les diagnostics d’erreur fournis par les différentes implémentations varient en fonction de leur pertinence pour décider d’une éventuelle action de recouvrement.

Une exceptionCORBAcomporte plusieurs champs, qui peuvent véhiculer des informa- tions annexes sur l’erreur qui a provoqué la levée de l’exception. Un premier champ annexe de toute exception CORBA est le minor code, un code entier qui permet au

4_{En effet, la longueur en octets du message est un entier non-signé codé sur 32 bits, et les messages}

affectés par la corruption sont de taille inférieure à 125 octets, donc inférieure à 27

. La majorité des bits codant cette longueur étant à zéro, leur inversion a une forte probabilité d’augmenter la taille annoncée du message.

courtier de fournir une information complémentaire sur la nature de l’erreur. Par exemple, une exception COMM_FAILURE associée à un code « échec de la tentative de connexion réseau » indique un problème sur le nœud distant, alors qu’associée au code « impossible d’accéder au réseau », elle indique plutôt un problème sur le nœud local. Les valeurs autorisées pour le code mineur sont spécifiques à chaque fournisseur. Certains courtiers ne renseignent pas ce champ de l’exception, et fournissent ainsi moins d’information pour le recouvrement au niveau applicatif.

Une seconde information complémentaire associée à une exception est son champ

completion status, qui permet à l’adaptateur d’objets de signaler si le traitement de

l’opération invoquée a été terminé ou non. L’état COMPLETED_NO indique que la de- mande d’exécution n’a pas été transmise au servant, et donc que le client peut répéter l’invocation, ou basculer vers un autre serveur. L’état COMPLETED_YES indique que le traitement de l’opération a été terminé. L’état le moins utile du point de vue du recouvrement est COMPLETED_MAYBE, qui indique que le courtier n’a pas pu dire si l’opération a été effectuée ou non.

La principale cause des exceptions avec COMPLETED_MAYBE est liée aux exceptions COMM_FAILURElevées par le courtier côté client. Lors de la rupture de la connexion réseau avec le nœud distant (suite par exemple à l’arrêt inopiné du processus léger qui gérait cette connexion), le courtier côté client n’est pas en mesure de savoir quel point du traitement de la requête a été atteint avant que la connexion ne soit interrompue. Dans cette situation, il lève une exception COMM_FAILURE avec le champ completion

status à COMPLETED_MAYBE.

La figure 3.7page suivante illustre la distribution des valeurs du champ completion

status en fonction du fournisseur. Pour chaque cible, toutes les SystemException

observées pour la campagne d’inversion de bits sur le service de désignations sont analysées. On voit sur cette figure que le candidat TAO est le seul à répondre par exception alors que l’opération a été terminée. Les candidats ORBit, IBM et omniORB présentent un plus fort taux de COMPLETED_MAYBE, ce qui est négatif.