6.7 Résistance aux comportements rationnels
6.7.5 Traitement des fautes d’omission
Dans cette section les déviations rationnelles et les motivations que nous allons présentées sont relatives à l’automate de la figure 6.8.
Déviation rationnelle : Les déviations présentes ci-dessous sont celles qui apparaissent respectivement aux transitions 1 et 2.
1. Un nœud rationnel peut ignorer un défi venant d’un de ses surveillants en refusant de le faire suivre.
2. Un nœud rationnel peut ne pas répondre à un défi.
Motivation : Les motivations ci-dessous vont pousser un nœud rationnel à exécuter respectivement les transitions citées ci-dessus.
1. Un nœud rationnel qui ignore une réception d’un défi risque une éviction, et pour éviter cela, il le fera suivre toujours.
2. La motivation précédente tient ici aussi.
6.8 Conclusion
Ce chapitre traite le problème de la mise en place de la notion de responsabilité dans les systèmes distribués en présence de comportements rationnels. Nous avons vu qu’appliquer PeerReview à lui même ne résout pas complètement ce problème et est très coûteux à mettre en place. C’est ainsi que nous avons proposé FullReview qui utilise différentes sortes de vérifications et des techniques de la théorie des jeux pour motiver ou forcer les nœuds rationnels à suivre toutes les étapes d’un protocole responsable (protocole assurant la notion de responsabilité dans un système distribué). FullReview utilise également l’architecture classique vue plus haut d’un système responsable.
Toutefois, proposer une solution à un tel problème ne suffit pas, il faut aussi voir si elle est pratique. Cela nous a amené à nous poser la question suivante : Existe-t-il une meilleure manière de configurer les surveillants d’un protocole responsable utilisant l’architecture classique, de telle sorte à avoir une bonne performance en terme d’échanges de messages ?
La réponse à cette question fera l’objet du chapitre prochain qui portera sur la gestion des surveillants dans un protocole responsable adoptant l’architecture classique.
7
Gestion des surveillants
Sommaire
7.1 Gestion statique . . . 56 7.2 Gestion dynamique . . . 57 7.3 Vers un système sans surveillants . . . 58 7.4 Évaluation . . . 60 7.4.1 SplitStream . . . . 60 7.4.2 Onion routing . . . . 61 7.5 Conclusion . . . 63
Dans les protocoles PeerReview et FullReview, nous avons vu que la surveillance est indispensable pour la mise en pratique de la notion de responsabilité dans un système distribué. Cependant, il est nécessaire de s’intéresser à la façon dont sont déployés les moniteurs (surveillants) selon la structure de l’application surveillée, car ils exécutent la majorité des tâches dans chacun des deux protocole cités ci-dessus.
Ainsi l’objectif de ce chapitre est d’étudier les différents scénarios de déploiement des moniteurs afin d’identifier ceux donnant de bonnes performances en terme d’échanges de messages.
Les travaux effectués dans le cadre de cette thèse nous ont amené à distinguer trois manières de gérer les surveillants : la gestion statique, dynamique et sans surveillants. Nous expliquons chacune de ces trois méthodes grâce au protocole PeerReview (les mêmes résultats s’appliquent aussi à FullReview de façon similaire) qui adopte l’ar-chitecture d’un système responsable, en s’intéressant uniquement aux sous protocoles coûteux (consistance, audit et transfert de preuve). La description de ces méthodes de gestion sera suivie d’une évaluation en utilisant deux applications : SplitStream et Onion routing.
7.1. GESTION STATIQUE
7.1 Gestion statique
C’est la gestion utilisée par défaut dans PeerReview et FullReview. Dans cette gestion statique, chaque nœud du système possède un nombre fixe de surveillants. Considérons ψ comme étant le nombre de surveillants, nous modélisons le nombre de messages échangés dans chacun des sous protocoles suivants :
Consistance : Dans ce protocole, si un nœud i reçoit un authentificateur de la part d’un autre nœud j, il le fait suivre aux surveillants de j, cela correspond à ψ(nombre de moniteurs par nœud) échanges. Ensuite, le transfert des authentificateurs extraits des surveillants du nœud i aux surveillants des nœuds qui les ont généré équivaut à ψ2échanges de message. Ces échanges sont illustrés sur la partie gauche de la figure 7.1.
Pour un système composé de N nœuds, si X est la moyenne du nombre d’au-thentificateurs générés (cette valeur dépend de l’application surveillée) et P la période d’audit, alors le nombre total de messages échangés durant ce protocole est donné par la formule N XP(ψ2+ ψ).
Audit : L’audit périodique de l’historique de chaque nœud nécessite2ψ échanges (2 échanges entre un nœud et chacun de ses surveillants) comme illustré sur la partie au milieu de la figure 7.1. Ainsi pour une période P d’audit, un nombre N de nœuds du système, le nombre total de messages échangés dans ce protocole vaut 2N P ψ. Dans FullReview, le nombre total de messages échangés durant ce proto-cole est estimé à N P(2ψ + ψ2). En effet comme décrit dans la section 6.6.1.1 (page 44), après avoir collecté les réponses d’audit, un nœud i agrège ces réponses et envoie le résultat à chacun des moniteurs de ses moniteurs. Ce processus coûte ψ2 (ψ est le nombre de moniteurs de i et chacun de ses moniteurs a aussi ψ surveillants) échanges de messages.
Transfert de preuve : Lorsqu’un nœud i veut connaitre le statut d’un autre nœud j, il contacte les surveillants du nœud j afin de s’informer. Cela équivaut à un échange de2ψ messages. Ensuite avec 2 échanges de messages, le nœud i met au défi le nœud j. Ces échanges sont illustrés sur la partie droite de la figure 7.1.
Finalement le nombre total de messages échangés durant cette étape de Peer-Reviewest égal à N lP(2ψ + 2) où l est le nombre de nœuds dont le statut est demandé par le nœud i.
Ce nombre d’échanges de messages diminue durant la même étape dans Full-Review. Cela est dû au fait que le résultat de l’audit d’un nœud i est envoyé aux surveillants des surveillants de i. Donc un nœud quelconque n’a pas besoin de contacter les surveillants d’un autre pour s’informer du statut de ce dernier. Par conséquent le terme 2ψ disparaît dans la formule précédente. Nous obte-nons2N lP comme étant le nombre de messages échangés durant cette étape de FullReview.
Le tableau 7.1 résume les échanges de messages ci-dessus. Pour résumer, la gestion dynamique des surveillants est modélisée en terme d’échanges de messages par les
formules suivantes :
• N XP (ψ2+ ψ) + 2N P ψ + N lP (2ψ + 2) dans PeerReview • N XP (ψ2+ ψ) + N P (2ψ + ψ2) + 2N lP dans FullReview.
Ces formules s’obtiennent en faisant la somme des échanges de messages dans chacun des sous protocoles concernés dans chaque cas.
FIGURE7.1 – Gestion statique : Scénario des échanges de messages.
Sous protocole Consistance Audit TP
Gestion statique PeerReview N X P(ψ2+ ψ) 2N P ψ N lP(2ψ + 2)
FullReview N X P(ψ2+ ψ) N P(2ψ + ψ2) 2N lP
Gestion dynamique PeerReview X P
!N i=1vi 2P!N i=1vi 2N lP FullReview X P !N i=1vi !N i=1P(2vi+ v2 i) 2N lP
Gestion sans surveillants PeerReview N X P R P N2R 2N lP
FullReview N X P R P N2R 2N lP
TABLE7.1 – Le nombre d’échanges de messages dans PeerReview comparé à
celui dans FullReview selon les différentes méthodes de gestion. TP = Transfert de Preuve