J'essaie d'implémenter la table de hachage distribuée de pâtisserie, mais certaines choses échappent à ma compréhension. J'espérais que quelqu'un pourrait clarifier.
Avertissement : je ne suis pas un étudiant en informatique. J'ai suivi précisément deux cours d'informatique au cours de ma vie, et ni l'un ni l'autre ne s'est occupé de quoi que ce soit de complexe à distance. Je travaille avec des logiciels depuis des années, donc je sens que je suis à la hauteur de la tâche de mise en œuvre, si je pouvais simplement tourner la tête autour des idées. Donc, je manque peut-être quelque chose d'évident.
J'ai lu l'article que les auteurs ont publié [1], et j'ai fait de bons progrès, mais je continue de me bloquer sur ce point particulier dans le fonctionnement de la table de routage:
Le document affirme que
La table de routage d'un nœud, , est organisée en lignes avec entrées chacune. Les entrées de la ligne de la table de routage se réfèrent chacune à un nœud dont nodeId partage le nodeId du nœud actuel dans les n premiers chiffres, mais dont ème chiffre a l'une des valeurs possibles autre que le ème chiffre de l'identifiant du nœud actuel.
Le représente une variable spécifique à l'application, généralement 4 . Utilisons b = 4 , par souci de simplicité. Donc, ce qui précède est
La table de routage d'un nœud, , est organisée en lignes avec entrées chacune. Les entrées de la ligne de la table de routage se réfèrent chacune à un nœud dont nodeId partage le nodeId du nœud actuel dans les n premiers chiffres, mais dont ème chiffre a l'une des valeurs possibles autres que le ième chiffre dans l'ID du nœud actuel.
Je comprends ça. De plus, est le nombre de serveurs dans le cluster. Je comprends ça aussi.
Ma question est la suivante: si la ligne dans laquelle une entrée est placée dépend de la longueur partagée de la clé, pourquoi la limite apparemment aléatoire du nombre de lignes? Chaque nodeId a 32 chiffres, lorsque (128 bits nodeIds divisé en chiffres de b bits). Alors, que se passe-t-il lorsque devient suffisamment haut pour ? Je me rends compte qu'il faudrait 340,282,366,920,938,463,463,374,607,431,768,211,457 serveurs (si mes calculs sont exacts) pour atteindre ce scénario, mais cela semble être une inclusion étrange, et la corrélation n'est jamais expliquée.N ⌈ log 16 N ⌉ > 32
De plus, que se passe-t-il si vous avez un petit nombre de serveurs? Si j'ai moins de 16 serveurs, je n'ai qu'une seule ligne dans le tableau. De plus, en aucun cas, chaque entrée de la ligne n'aurait un serveur correspondant. Les entrées doivent-elles être laissées vides? Je me rends compte que je serais en mesure de trouver le serveur dans le jeu de feuilles, peu importe quoi, étant donné que peu de serveurs, mais le même dilemme est soulevé pour la deuxième ligne - et si je n'ai pas de serveur qui a un nodeId de telle sorte que je puisse remplir toutes les permutations possibles du nième chiffre? Enfin, si j'ai, disons, quatre serveurs, et j'ai deux nœuds qui partagent, disons, 20 de leurs 32 chiffres, par un hasard aléatoire ... dois-je remplir 20 lignes de la table pour ce nœud, même si c'est beaucoup plus de rangées que je ne pourrais même en approcher?
Voici ce que j'ai trouvé, en essayant de raisonner mon chemin à travers cela:
- Les entrées doivent être définies sur une valeur nulle s'il n'y a pas de nœud correspondant exactement à ce préfixe.
- Des lignes vides doivent être ajoutées jusqu'à ce que suffisamment de lignes existent pour correspondre à la longueur partagée des nodeIds.
- Si, et seulement si, il n'y a pas d'entrée correspondante pour un ID de message souhaité, retombez sur une recherche dans la table de routage pour un nodeId dont la longueur partagée est supérieure ou égale aux nodeId actuels et dont l'entrée est mathématiquement plus proche que l'actuelle nodeId est à l'ID souhaité.
- Si aucun nœud approprié ne peut être trouvé dans # 3, supposez qu'il s'agit de la destination et remettez le message.
Ces quatre hypothèses sont-elles valables? Y a-t-il un autre endroit où je devrais chercher des informations à ce sujet?
- Pâtisserie: localisation et routage d'objets décentralisés et évolutifs pour les systèmes peer-to-peer à grande échelle par A. Rowstrong et P. Druschel (2001) - télécharger ici