Date de publication du RFC : Septembre 2014
Auteur(s) du RFC : J. Maenpaa, G. Camarillo (Ericsson)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF p2psip
Première rédaction de cet article le 7 septembre 2014
Le mécanisme RELOAD est un mécanisme pair-à-pair pour créer un réseau virtuel au-dessus des réseaux existants, notamment aux fins de téléphonie, messagerie instantanée et diffusion multimédia. Ce RFC étend le protocole Chord tel qu'utilisé par RELOAD de manière à permettre l'ajustement automatique de la DHT à des conditions changeantes (par exemple une augmentation ou diminution du taux de changement des pairs, le churn).
C'est le RFC 6940 qui normalise
RELOAD. RELOAD offre le choix de plusieurs algorithmes de gestion du
réseau virtuel mais, afin
de permettre l'interopérabilité de toutes les machines RELOAD, il
existe un algorithme obligatoire, que toute mise en œuvre de RELOAD
doit connaître. Les autres algorithmes ne pourront être utilisées que
si toutes les machines du réseau sont d'accord. Cet algorithme
obligatoire se nomme CHORD-RELOAD
et repose sur
la DHT Chord. Comme
toutes les DHT, Chord s'organise tout seul (pas besoin de chef pour
créer le réseau virtuel), passe bien à
l'échelle et est très résilient. Pour maintenir la DHT,
les machines échangent des informations sur leur état et
reconfigurent le réseau virtuel si nécessaire. Pour être le plus optimisé possible,
afin de limiter le trafic réseau de gestion, ce travail dépend de
paramètres comme le taux de changement des pairs (le
churn), ou la taille du réseau. Souvent, ces
paramètres sont fixés à l'avance lors de l'initialisation de la
DHT. Ce n'est évidemment pas satisfaisant car ils peuvent varier dans
le temps. Ils servent à calculer des caractéristiques de la DHT comme
la taille de la liste des successeurs, ou comme la taille de la table
de routage. Ces caractéristiques devraient pouvoir changer dans le
temps, elles aussi. (Voir l'article de Mahajan, R., Castro, M., et A. Rowstron, « Controlling the
Cost of Reliability in Peer-to-Peer Overlays ».)
Ces mécanismes de stabilisation qui tournent pour maintenir la DHT sont de deux types, périodique ou bien réactif. Dans l'approche périodique, les informations sont régulièrement échangés entre pairs, qu'il y ait eu des changements ou pas. La DHT est ajustée s'il y a du changement. Dans l'approche réactive, les pairs transmettent la nouvelle information lorsqu'il y a un changement et la DHT s'ajuste alors. On voit que l'approche réactive permet des ajustements plus rapides mais qu'elle écroule vite le réseau si le nombre de changements est trop important, notamment parce qu'elle peut entraîner une boucle de rétroaction. (Voir l'article de Rhea, S., Geels, D., Roscoe, T., et J. Kubiatowicz, « Handling Churn in a DHT ».) Le Chord de RELOAD permet d'utiliser les deux approches, alors que la plupart des mises en œuvre d'une DHT n'utilisent que la stabilisation périodique. La période de diffusion des informations fait partie de ces paramètres qu'on voudrait voir évoluer dynamiquement.
La section 4 de notre RFC résume ce qu'il faut savoir de Chord pour comprendre les changements introduits (je ne la répète pas ici). Les sections 5 et 6 décrivent ces changements, qu'est-ce qui peut être modifié dynamiquement et quand.
Ces changements se traduisent par des nouveaux enregistrements
dans les
registres IANA RELOAD : nouvel algorithme de gestion du réseau
virtuel CHORD-SELF-TUNING
, nouvelle extension
self_tuning_data
, etc.
Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)
Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)