SPÉCIFICATION DES EXIGENCES POUR UN ROUTAGE PAIR-À-PAIR EFFICACE
Le routage efficace
Les systèmes P2P assurent un passage à l’échelle et supposent une communauté de pairs fortement dynamique et assez hétérogène (notamment en termes de capacités réseaux). Mais leurs performances globales dépendent largement des performances du protocole de routage mis en œuvre en arrière-plan. Pour être efficace, un protocole de routage P2P doit pouvoir : − être consistant, c.-à-d. garantir qu’un message relatif à une clé parvienne au nœud responsable de cette clé (et pas à un autre nœud) ; − rester robuste même en cas de forte dynamique des pairs : être fiable en toutes conditions réseaux (c.-à-d. garantir qu’aucun message ne se perde) ; être stable (c.-à-d. garantir la mise à jour rapide des données du système, avec un minimum de messages à échanger) ; garantir une bonne tolérance aux pannes (c.-à-d. qu’un chemin vers la destination soit trouvé même en cas de rupture de liens ou de disparition imprévue de pairs (e.g. panne, attaque, etc.)) ; ne pas être affecté par les pairs peu fiables partageant des ressources ; − être efficient : assurer une convergence rapide (c.-à-d. garantir un temps de réponse court avec un temps de latence minimal) ; transmettre les messages à moindre coût (le coût total est le nombre de sauts, chacun éventuellement combiné à son coût individuel) ; optimiser voire minimiser l’usage des ressources du système ; − garantir le passage à l’échelle : quand le nombre de processeurs actifs augmente, le système doit : rester robuste et efficient (comme décrit ci-haut) ; conserver des tables de routage de taille raisonnable ; − assurer un bon équilibrage de charge (des pairs et des objets) dans l’espace d’identification overlay, ainsi qu’un bon équilibrage des différents flux de trafic dans le réseau ; − s’adapter au réseau underlay (critère détaillé au paragraphe suivant 2.2) ; − respecter la philosophie du pair-à-pair et viser le symétrique, notamment dans le cas des architectures hybrides. En ce sens qu’un super-pair ne doit pas garder un monopole indéfini sur les autres pairs de son clan et chaque nœud doit pouvoir être racine ; − offrir la possibilité de sécuriser le système (les infrastructures, les applications et les pairs) pour : prévenir et pallier les comportements malicieux (e.g. pair malicieux, faux-contenu si les objets sont des fichiers, surcharge ciblée, messages parasites, etc.) ; éviter qu’un comportement malicieux ne puisse corrompre l’état ou le fonctionnement du système ; pouvoir garder une traçabilité légale et protectrice des mouvements du système ; − permettre le cloisonnement des ressources et garantir la localité du contenu et du chemin, afin de : améliorer les performances (notamment les temps de réponse) ;
Adéquation du routage pair-à-pair au réseau sous-jacent
Nous avons vu au chapitre précédent que le routage dans les systèmes P2P dépend principalement de l’architecture du système, mais aussi du protocole qui lui est relatif. En tout cas, pour un même réseau, les topologies overlay et underlay sont souvent bien différentes : − la topologie au niveau overlay reflète la disposition des liens entre les pairs ; − et la topologie au niveau sous-jacent considère plutôt les distances « physiques » entre les pairs. Ces distances, dans un réseau IP, sont généralement mesurées en termes de RTT (Round Trip Time), qui estime le temps d’aller-retour d’un paquet entre deux nœuds. Du coup, un saut entre deux pairs voisins au niveau overlay ne signifie pas nécessairement que les deux pairs sont proches au niveau underlay (cf. fig. 2.1). Ceci est d’autant plus vrai qu’un réseau P2P ne prend pas naturellement en compte les caractéristiques du réseau underlay.