Optimisation de l'architecture

Le premier paramètre étudié lors de notre évaluation est l'impact du temps sur l'ecacité de l'architecture an de connaître le temps minimum d'exécution de l'architecture lui perme-ttant d'être parfaitement fonctionnelle. En eet, les Honeypeers lorsqu'ils rejoignent le réseau, comme n'importe quel autre client, ont besoin d'un certain temps, appelé phase d'initialisation ou d'amorçage, durant lequel ils s'annoncent activement an d'être connus des autres pairs du réseau. A plus long terme, KAD privilégiant les contacts stables, une longue période d'exécution ininterrompue pourrait également impacter l'ecacité de l'architecture.

Le graphique 5.5 montre, pour chaque intervalle de 6 heures, le nombre de requêtes de pub-lication reçues par HAMACK pendant deux jours. Les requêtes sont capturées après un quart

Figure 5.5  Impact du temps d'exécution sur l'ecacité d'HAMACK

d'heure réservé à l'initialisation de l'architecture. Nous pouvons clairement observer que le temps d'exécution n'a pas inuence sur l'ecacité de l'architecture. Nous pouvons également remar-quer que le nombre de requêtes reçues durant l'après-midi (∼ 40000) entre 12h-18h ou 18h-00h (GMT+1) est plus élevé que durant la matinée (∼ 30000) entre 00h-06h ou 06h-12h. Bien que le nombre de pairs à l'échelle du réseau soit stable dans le temps, la capture des requêtes étant réalisée à travers l'observation de mots-clés dénis dans un alphabet et une langue, celle-ci est liée à une zone géographique particulière (ici l'Europe), ce qui explique l'eet journalier. Il est donc nécessaire de considérer une journée complète pour ne pas être soumis aux variations horaires lors de l'évaluation des performances de l'architecture.

Parmi les paramètres pouvant aecter l'ecacité de l'architecture, connaître le nombre de Honeypeers déployés pour superviser une même référence est important an de limiter le nombre d'instances nécessaires et ainsi limiter la consommation de ressources. Le nombre minimum de Honeypeers devrait être de 10, c'est à dire le facteur de réplication de KAD en dessous duquel on ne peut capturer toutes les requêtes. Cependant, comme plusieurs requêtes de services sont envoyées en parallèle, il est fréquent que plus de 10 requêtes soient émises avant que le service ne soit réalisé. Par conséquent, nous considérons un nombre minimum de 15 Honeypeers nécessaires pour superviser une référence. Le graphique 5.6 montre le nombre de requêtes capturées alors que le nombre de Honeypeers varie entre 15 et 25. Les résultats montrent que l'utilisation de 20 Honeypeers améliore signicativement l'ecacité d'HAMACK par rapport à 15. En revanche l'utilisation de 25 Honeypeers ou plus est inutile.

Après avoir étudié les principaux paramètres d'exécution, nous avons évalué trois autres paramètres aectant le comportement des Honeypeers. Nous avons tout d'abord mesuré l'impact de leur collaboration. Celle-ci force les Honeypeers à se connaître explicitement grâce à la base de données et à se promouvoir lorsqu'ils reçoivent une requête de localisation concernant la

Figure 5.6  Impact du nombre de Honeypeers déployés sur l'ecacité d'HAMACK

référence supervisée. Sans collaboration, les Honeypeers n'ont pas de connaissance a priori les uns des autres et se découvrent et se propagent naturellement par les mécanismes KAD. Nous pouvons constater dans le graphique 5.7 que cette modication a un impact positif sur le nombre de requêtes de publication capturées sur une journée (+23%).

Ensuite nous avons étudié l'inuence du nombre de contacts retournés lors d'une demande de localisation. En eet, ce paramètre peut varier selon le type de service préparé. Les dernières versions des clients KAD (eMule 0.49c et aMule 2.2.4) vérient que le nombre exact de contacts attendus est retourné. Ainsi, ces clients rejettent toute réponse contenant plus que 4 contacts potentiels pour un service de publication ou de recherche. Cependant, ces versions étant très récentes au moment des tests (moins de 2 mois), la plupart des clients n'implantaient pas cette contrainte. Par ailleurs, augmenter le nombre de contacts par réponse de manière à propager l'ensemble des Honeypeers en une seule réponse améliore leur visibilité. Il est donc intéressant d'évaluer la meilleure stratégie. Le graphique 5.8 montre que le Honeynet capture davantage de requêtes de publication (+45%) en respectant les dernières contraintes implantées. Cela signie qu'une partie signicative du réseau P2P met à jour son client dès que possible et, par conséquent, toute nouvelle contrainte implantée dans les clients ociels doit être immédiatement considérée. Enn, nous avons évalué le fait d'annoncer activement les Honeypeers dans le réseau en émet-tant périodiquement des requêtes de localisation vers des identiants aléatoires de la DHT. Le graphique 5.9 montre que cette modication est inutile et n'apporte aucun gain à l'architecture, les algorithmes de routage et de maintenance des tables mis en ÷uvre dans KAD étant déjà susamment performants pour que les Honeypeers soient bien référencés.

5.3.3 Évaluation de l'attractivité des Honeypeers

Évaluer l'ecacité globale de l'architecture est très délicat. Une approche naïve consisterait à instrumenter chaque pair du réseau an de connaître la proportion eective de requêtes cap-turées par HAMACK. Nous avons néanmoins conçu deux expériences permettant de fournir un indicateur sur son ecacité. Nous avons déployé l'architecture composée de 20 Honeypeers sur un mot-clé du réseau KAD, activant la collaboration et retournant 4 contacts par requête de localisation.

Figure 5.7  Impact de la collaboration entre Honeypeers

Figure 5.9  Impact de l'annonce active des Honeypeers

La première expérience réalisée a pour objectif de vérier que l'architecture parvient bien à attirer toutes les requêtes pour l'identiant supervisé. Pour cela, nous avons publié un mot-clé supervisé par HAMACK depuis 8 pairs diérents que nous avons instrumentés. Pour éviter toute mesure biaisée par des conditions initiales similaires, chacune des 8 sources a une place aléatoire dans la DHT et a rejoint le réseau depuis une liste diérente de contacts. Étant donnée cette conguration, nous comparons, pour chaque publication, le nombre de requêtes émises par les diérentes sources et celui constaté par HAMACK pour chacune de celles-ci. Le graphique 5.10 montre que toutes les requêtes émises sont capturées par les Honeypeers, comme le laissait supposer l'analyse de la procédure de recherche de KAD. Le nombre de requêtes émises (entre 10 et 12) correspond au facteur de réplication (10) nécessaire pour publier un chier, plus quelques requêtes supplémentaires émises avant la n du service.

La seconde expérience consiste à compter le nombre de requêtes de publication capturées par HAMACK venant d'un même pair et pendant une courte période de temps. En eet, chaque donnée indexée dans KAD est prise en charge par 10 pairs constituant autant de réplicats. Sans au moins dix réponses armatives, la publication n'est pas satisfaite. Ainsi, chaque fois que l'ar-chitecture reçoit moins de 10 requêtes répliquées durant l'intervalle de temps d'une publication, des requêtes ont potentiellement été manquées. Le graphique 5.11 compte le nombre de publi-cation pour chaque valeur de réplipubli-cation observée. Les résultats sont très satisfaisants. En eet, peu de publications sont observées avec moins de 8 réplicats (8.9%) et comme attendu, la grande majorité des réplicats capturés se situe autour de 10.

Finalement, nous avons mesuré la distribution des requêtes capturées sur l'ensemble des 20 Honeypeers supervisant une même référence pendant une journée. En ordonnant les Honeypeers par rapport à leur distance XOR à la cible, le graphique 5.12 montre que la distribution de la charge entre les Honeypeers est liée à cette distance : plus un Honeypeer est proche de la cible, plus il reçoit de requêtes. Bien que les Honeypeers soient plus proches que n'importe quel autre pair de la cible du fait des 96 bits communs avec la cible, et malgré leur collaboration, ils restent néanmoins en concurrence pour attirer les réplicats. Ainsi, la liberté de choisir les 32 bits restant est susante pour procurer un gain d'attractivité signicatif aux Honeypeers qui se rapprochent de la cible, ce qui montre que l'algorithme de KAD parvient toujours à localiser les pairs les plus proches même dans ces conditions extrêmes. Ayant la connaissance des identiants

Figure 5.10  Nombre de requêtes de publication capturées pour les diérentes sources

Figure 5.12  Distribution de la charge sur les Honeypeers

des Honeypeers, nous avons remarqué que les Honeypeers avec les identiants entre 1 et 13 ont choisi le 97ème bit conformément à la cible alors que les autres entre 14 et 22 ont choisi l'autre valeur, ce qui est visible graphiquement car l'ecacité de ces derniers décroît signicativement avec la perte d'un bit commun. Ces résultats indiquent également que les pairs normaux, étant en comparaison très éloignés de la cible, ont peu de chance de recevoir des requêtes au détriment des Honeypeers.