公平DHT的实施

时间:2015-10-18 12:06:34

标签: distributed p2p dht peer

我正在考虑一个基础设施,许多用户连接到一台服务器,并使用哈希值存储键值对。

存在许多此类服务器,每个服务器都存储其自己用户的键值对。我们假设密钥不会发生冲突。

服务器S1上的用户U1可能会查找具有密钥K2的对象,密钥K2位于服务器S2上(用户还不知道这一点)。我们需要某种分布式哈希表来将一个键映射到server_addr,这样我们就可以在该服务器上查询该对象。

有很多这样的DHT,比如Tapesry,Chord等。我一直在考虑如何制作这样的系统。

例如,在具有三个服务器的系统中,服务器S1可以具有1000个用户,S2具有2个用户,S3具有5个用户。如果我们假设用户各自创建10个对象并且我们统一分配密钥空间,则服务器S2和S3将分别存储大约3500个密钥,这比他们自己的密钥消耗大一个数量级或两个数量级。

我希望S1能够对DHT中公平分配的密钥负责。

我有一个想法就像是一个审计系统,每个对等方都要求其他人在DHT中存储了多少个密钥,然后检查它们是否也负责关键空间的这一部分。

但是,这会导致大量使用带宽以消耗每个节点。

还有其他想法吗?

1 个答案:

答案 0 :(得分:1)

有几种可能的方法

什么都不做

野外DHT不是完全同质的环境。一些节点拥有比其他节点更多的资源(嵌入式设备与胖服务器)。有些节点创建的活动比其他节点多。

节点可以根据其能力简单地呈现服务(路由,存储),并在达到其容量后拒绝请求(通过丢弃或返回否定响应)。

发出请求的节点只会将它们视为故障并绕过故障点进行处理。

你基本上应该检查一下节点消耗的资源比其他节点多几个数量级的情况,这通常足以保证平衡。

自愿措施

导致更多流量的节点可能只是为了提供更多资源而设计的。例如。它可以运行遍布密钥空间的多个虚拟节点,从而为更多密钥提供存储和路由。

对于具有高正常运行时间,带宽和低延迟的服务器级计算机而言,这应该特别容易。

执行

这是棘手的地方。在分布式系统中,您没有信任或监管权限。在您提供服务请求之前,节点必须证明它提供了足够的服务。

第一个明显的衡量标准是其他节点担保它确实提供了它声称的服务。但这仅仅提供了它提供某些服务的证据,它没有提供有关提供和消耗资源之间比率的任何信息。而且你还需要一种机制来验证它确实存储了它声称的数据,而不仅仅是返回正面响应然后丢弃它们。

因此,您需要会计,验证和信任网络,因为单跳优惠券可能不足。

正如您所看到的,复杂性很快就会爆炸。

您可能应该从更大的角度来看待并确定攻击者和网络中的好公民所拥有的激励措施。

  • 消耗过多资源可以获得什么
  • 验证的成本是多少(复杂性,人力,与防止恶意流量相关的流量开销)
  • 异常值真的会导致多少负担?