我对如何在Distributed Hash Table算法（CHORD）中进行节点发现感到困惑。假设每个节点都可以通过多播访问。为什么下面的情况会很糟糕：
没有回应，决定它是独自的。
第二个节点到达。
相邻节点也开始向这个新到达节点发送必要的键值对。
客户端向节点询问密钥，每个节点都知道该密钥对应的IP /端口。询问KEY-VALUE对的节点并将其返回给客户端。
现在我认为这种情况很糟糕，因为每个节点都无法保留HUGE系统中所有节点的列表。我对么？
但是，节点怎么能发现它所谓的FINGER TABLE？
我知道bittorrent将中央服务器作为DHT系统的起始节点。如果我们假设我们可以通过多播到达每个节点，是否可以消除此服务器？
提前致谢。很抱歉有多个问题，但我不认为我无法用一个问题表明我的困惑。
答案 0 :(得分：1)
您似乎在混淆两个不同的问题：
既然你提到了多播，那么它将属于1.我会专注于它，2。一旦你得到第一个节点并且没有特定于组播的属性，它就是bog-standard。
因此，如果您处于可用组播的受控环境中并且您想要引导DHT，那么您可以让所有节点加入相同的多播组，并偶尔宣布它们的存在。这里的问题是天真的实施不会扩展。流量会随着节点数量的增长而增长。
但解决方案非常简单，在看到广告包时给每个节点randomized, exponential backoff。 换句话说，无论DHT中的节点数量如何，飞行中的广告消息量都应保持不变。
谁发送广告包并不重要。节点不一定要宣布自己。接收数据包以了解任何其他节点，然后根据收到的数据包开始填充其路由表就足够了，如果需要。
节点在稳态操作期间不应与广告节点联系，因为它们已经具有填充的路由表。他们不需要。如果可能有数百或数千个节点这样做，它们将压倒当前的广告节点。
为了进一步扩展负载，广告节点还可以包括从其路由表到广告的随机节点列表，以便当前自举节点可以随机选择一个。
如果您对发送或引导过程有其他问题，而不是特定于多播，我建议您创建新问题。