我正在尝试了解分布式哈希表（DHT）范式，因为它适合 P2P 或完全分布式计算架构。从理论的角度来看，一旦建立了集群，它如何管理集群数据和分配工作就有意义了。
对我来说最有趣的部分是该架构从不需要某种集中控制器或协调器（没有单点故障）。但是，我仍然在努力理解这个概念的实际执行，特别是集群是如何形成的。如果是完全分布式系统，节点如何知道如何“加入”已经建立的集群？
举个简单的例子：
那么，如果没有任何集中式服务器充当信标，或者提供将新客户端引入集群的手段，新客户端将如何“连接”？
这是我在论文中讨论的一个问题，但我从未找到令我满意的解决方案。问题是，在加入网络之前，您只需要有关其他对等点之一的某种信息，获取第一个地址是困难的一点。
我想到的一些想法：
最后一个选择是唯一真正去中心化的方法。三者的结合可能是最好的。
一旦启动网络，断开连接后重新建立连接并不困难，只需保存网络中数千个已经长期存在的节点的地址，至少其中一个下次仍会在线。
据我所知，您可以为 DHT 节点网络创建一个代理服务器，并为该代理服务器提供影子服务器以实现可靠性。
任何尝试加入 DHT 网络的新节点都会与代理通信，代理会允许其进入完全 P2P 的 DHT 网络。
这样只有代理服务器必须是公共的，所有其他 DHT 节点都可以拥有其私有 IP。
这可能会对您造成阻碍，因为应用程序分布在互联网上，但您始终可以通过代理进行交谈。
事实上，维护分布式哈希表 (DHT) 源主干的一方是该 DHT 实例的“GOD”，因此是“main”单点故障。如果 DHT 从匿名网络（Tor、GNUnet、Chimera 等）节点（以下简称：anonnodes）引导，且其地址已硬编码到 DHT 源中，则该 DHT 的可能性被某些“无此类机构”劫持的情况不应增加。如果与 torsocks 结合使用，经典的 wget 可与 Tor 网络地址配合使用。一个例子：
torsocks wget http://xmh57jrzrnw6insl.onion/
为了降低 DHT 通过劫持某些引导节点而被劫持的风险，可以使用自动投票流程。这个想法是，引导节点从硬编码的匿名节点获取地址列表，并且仅从大多数列表中存在的节点进行引导。如果某些匿名节点比其他匿名节点更“可信”，那么“更可信”的匿名节点可以拥有不止一票，而不是使用每个匿名节点拥有一票的系统。
在过去，当计算机不可靠时，投票系统的使用形式是，同一台计算机在同一组汇编命令上多次运行，而不是使用不同的投票计算机。比较计算结果。最常见的答案被认为是正确的。可能在分布式哈希表的情况下，可能会使用相同的方法：在某个“较长”时间段内通过不同的 Tor 会话多次向不同的引导节点询问相同的问题、已知的 DHT 节点列表。
截至 2014_07_xx，我尚未测试这些想法，但我希望我当前的评论有所帮助。
有关节点如何加入 DHT 覆盖层的详细信息可能会受到限制。但是，您只能获得有关如何发现对等点以及如何在它们之间共享信息的详细信息。我通过查看具体实现简化了这一点。您可以直接深入研究的一种实现是
Kademlia Protocol