0

我对如何在分布式哈希表算法 (CHORD) 中进行节点发现感到非常困惑。假设每个节点都可以通过多播到达。为什么以下情况会不好：

  • 一个节点开始工作
  • 组播到达网络

  • 没有任何反应，决定它是孤独的。

  • 第二个节点到达。

  • 组播到达网络。
  • 所有节点都收到到达并使用节点的密钥更新它们的 NodesList。
  • 然后将这个新的 nodeList 返回给新的到达者。

  • 相邻节点也开始向这个新到达的节点传输必要的键值对。

  • 客户端向节点询问密钥，每个节点都知道该密钥对应的 ip/port。向该节点询问 KEY-VALUE 对并将其返回给客户端。

现在我认为这种情况很糟糕，因为每个节点都无法保留一个巨大系统中所有节点的列表。我对么？

但是，节点如何发现其所谓的 FINGER TABLE 呢？

我知道 bittorrent 将中央服务器作为 DHT 系统中的起始节点。如果我们假设我们可以通过多播到达每个节点，是否有可能消除该服务器？

提前致谢。很抱歉有多个问题，但我认为我无法用一个问题证明我的困惑。

4

1 回答 1

1

您似乎将两个不同的问题混为一谈：

  1. 发现第一个与之交谈的节点
  2. 填充路由表

既然您提到了多播，那将属于 1. 我将重点关注这一点，2. 一旦您获得第一个节点并且没有特定于多播的属性，它就是沼泽标准。

因此，如果您处于多播可用的受控环境中并且您想要引导 DHT，那么您可以让所有节点加入同一个多播组并偶尔宣布它们的存在。这里的问题是幼稚的实现不会扩展。流量会随着节点数量的增加而增长。

但是解决方案很简单，当每个节点看到一个广告包时，给它一个随机的指数退避。换句话说，无论 DHT 中的节点数量如何，传播中的广告消息的数量都应该保持不变。

谁在发送广告包并不重要。节点不一定要宣布自己。接收数据包以了解任何其他节点，然后根据接收到的数据包开始填充其路由表（如果需要）就足够了。

节点在稳态操作期间不应联系广告节点，因为它们已经有一个填充的路由表。他们不需要。如果可能有成百上千个节点这样做，它们将压倒当前的广告节点。

为了进一步分散负载，广告节点还可以将其路由表中的随机节点列表包括到广告中，以便当前引导节点可以随机选择一个。

如果您对发现或引导过程有其他问题，这些问题并非特定于多播，我建议您创建新问题。

于 2015-01-26T21:21:35.647 回答