Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

RFC 7363: Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)

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.


Téléchargez le RFC 7363

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)