如果您创建一个使用分布式哈希表（DHT）的新应用程序，您需要引导p2p网络。我认为您可以加入现有的DHT（例如Bittorrent DHT）。这可行吗？当然，我们假设使用相同的技术。将Chord与Kademlia结合显然不可行。如果是，这是否被视为寄生或共生？寄生意味着它在某种程度上与原始用途冲突。共生，如果对于两个应用程序都有好处，因为它们互相支持。
1个回答
5
一般来说：Kademlia和Chord只是抽象设计，而实现提供不同的功能。如果其功能集过窄，则无法将应用程序逻辑映射到其上。如果其功能过于广泛，则在没有开源库可用的情况下重新实现可能会很痛苦。
对于比特流：比特流DHT提供20字节密钥 ->列表[IP，端口]查找作为其主要功能，其中IP由发送方IP确定，因此无法用于存储任意数据。还有一些次要功能，如对这些列表的布隆过滤器统计信息，但它们对其他应用程序可能甚至更少有用。
它不提供通用键值存储，至少不作为核心规范的一部分。有一个扩展提案。
虽然实现通过将未知消息类型视为节点查找请求而不是忽略它们，提供了一些基本的向前兼容性，但如果您的应用程序提供了节点的一小部分，那么这仅有限度的有用，因为您不太可能在查找期间遇到实现该功能的其他节点。
“如果是这样，这是否被认为是寄生或共生关系？”
这在很大程度上取决于你是否是网络中的“好公民”。
对于比特流：比特流DHT提供20字节密钥 ->列表[IP，端口]查找作为其主要功能，其中IP由发送方IP确定，因此无法用于存储任意数据。还有一些次要功能，如对这些列表的布隆过滤器统计信息，但它们对其他应用程序可能甚至更少有用。
它不提供通用键值存储，至少不作为核心规范的一部分。有一个扩展提案。
虽然实现通过将未知消息类型视为节点查找请求而不是忽略它们，提供了一些基本的向前兼容性，但如果您的应用程序提供了节点的一小部分，那么这仅有限度的有用，因为您不太可能在查找期间遇到实现该功能的其他节点。
“如果是这样，这是否被认为是寄生或共生关系？”
这在很大程度上取决于你是否是网络中的“好公民”。
- 您的实现是否遵循规范，包括常用扩展？
- 当涉及到造成的流量时，您的一般使用情况是否与其他节点相比保持在数量级内？
- 应用程序的生命周期是否足够长，不会超出目标DHT预期的变动率？
- the8472
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接