有不同形式的节点故障。
最常见的一种是节点离线,因为运行 DHT 的应用程序已关闭。
国内互联网连接的动态 IP 的更改本质上具有微妙的不同效果,因为它会使所有现有的路由表条目无效,但总节点数不会下降。你失去一个,你得到一个新的。
另一个常见问题是由于 NAT 导致的可达性问题。该节点的可见性可能取决于 NAT 类型以及您最近是否接触过它。
流失的结果实际上可能非常复杂。首先,单个节点的正常运行时间通常遵循指数分布。许多只能在短时间内使用,很少有人能稳定几天或几个月。
假设你有一个稳定的核心,由中等到长寿命的节点组成,实际上构成了网络的 90%。10% 的相同节点不断出现和消失会导致一些开销流量,但它们不会对网络造成太大损害。你有很多流失但影响很小。
如果 10% 的节点群在 10 分钟后脱机并被非活动池中的一组全新节点替换,那么您实际上每 10 分钟就会失去 10% 的冗余。如果节点之间的数据复制跟不上或者甚至不存在,您的数据将呈指数衰减。你也有很多流失,但影响很大。
我什至不确定哪种模拟能最好地反映现实。我想最现实的限制就是拥有一个固定的潜在节点池。那是安装了 DHT 实现的计算机。
然后每个节点都会有一个时间概况,它平均保持多长时间以及平均下降多长时间(这两个参数彼此部分相关。长时间正常运行的节点通常不会有很长的停机时间因为他们可能永远在线)。并且每个节点独立地作用于这些参数。实际上,一天中的时间也起着重要作用,在这里可以很容易地看出:http: //dsn.tm.uni-karlsruhe.de/english/2936.php
所以......长话短说,只是随机运行和杀死几个节点不会给你一个关于 DHT 弹性的现实结果,因为影响会千差万别。
至于技术部分,您可能希望在同一个 java VM 中运行所有这些,并使用多线程或非阻塞 IO 来减少在单独的 VM 中运行每个实例的开销。这也将允许您以更现实的方式安排他们的运行和停机时间。
由于您可以将多个 IP 分配给单台计算机,因此您应该能够仅根据 IP/端口数在计算机上运行数十万个节点。但是,即使是最快的系统,该过程的资源消耗最终也会陷入困境,因为实际上很少有 DHT 实现能够很好地扩展。
因此,您可能需要在每台计算机有几千个节点的网络上运行它,以获得接近现实的任何东西。
要么,要么你求助于更多的数学模拟,而不是运行实际的实现。