P2P网络中的空间搜索可能吗?

时间:2012-02-19 19:46:46

标签: geolocation social-networking geospatial p2p

我想构建一个基于Javascript / HTML5地理位置的社交网络,我想知道可能的架构的最佳选择。客户端 - 服务器可以很容易开发,但缺点是系统资源可能非常高,特别是因为应用程序必须管理移动(最坏的情况:在汽车中的用户必须看到汽车周围的其他用户)。

基本上,在客户端 - 服务器架构中,服务器任务将是:

  1. 收集并存储用户的纬度和经度(可能有数千个)
  2. 对该用户进行地理距离搜索(以获取半径内存在的用户列表)
  3. 构建并向客户端发送一个XML文件,该文件包含列表中用户的位置
  4. 这3个操作必须每隔3或5秒定期进行,因为我想要一个“实时”地图,显示列表中的用户在他们的环境(城市,城镇)中移动。

    所有这三点都可以优化:

    1. 客户端在移动10米时发送其位置以减少要处理的数据量
    2. “球形矩形”在MyISAM表中搜索空间索引(使用MBRContains)来卸载MySQL数据库。
    3. 公共输出文件:如果2个用户位于半径x米(2个用户彼此靠近),则发送的XML可以相同。
    4. 在这个阶段很难进行负载估算,但我认为客户端 - 服务器架构不适合这种类型的应用程序,如果2个客户端彼此靠近时可以进行通信,则peer2peer可能是一个很好的答案。

      我的观点是:

      是否有任何方法可以让客户在没有中央服务器帮助的情况下盲目搜索位于某个半径的其他客户端? (可以使用UDP广播: - )

      编辑:更正。 UDP Brodcast允许客户端在特定范围或IP地址中的任何地方轮询机器。

      感谢您的帮助, Florent的

2 个答案:

答案 0 :(得分:-1)

您必须拥有中央对等/服务器,因为您需要集中一些信息才能执行功能。

我会选择以下内容:

  1. 将平方英里(或任何您想要的尺寸)分配给特定服务器。

  2. 让设备将“我在这里”的消息及其坐标发送给某个调度员,调度员将这些消息转发到正确的平方英里服务器进行处理。

  3. 当设备进入他们管理的平方英里时,让服务器注册。这可以是一个中心地图,以确保设备注册到一个且只有一个方格。

  4. 将此讯息转发给广场上的所有其他设备。

  5. 和/或确保将此消息包含在哪个方格中,并确保设备在将其显示给用户之前对其进行检查。

  6. 调整方块的大小和“我在这里”的消息。就是这样。

答案 1 :(得分:-1)

答案实际上取决于很多事情,所以我会帮助解决基本策略。要理解这些内容,您需要了解Kademlia的工作原理(Kademlia是一个存储信息的DHT P2P网络)。

在Kademlia首次启动时,每个节点都会选择一个随机ID,这是一个160位数字,表示所有可能的160位ID空间中的点。

需要存储的信息的ID是使用SHA-1函数获得的(它接收任意字符串,并输出160位数,其被视为需要存储的信息的ID)

之后您拥有信息的ID,并将其发布,信息实际存储在其ID接近信息ID的节点上。

(插图取自here

enter image description here

通过它的ID查询信息。信息查找或节点查找都采用O(log(N))跳来获取所需信息。 “XOR”度量标准用于Kademlia(在您的情况下,它可以是普通的欧几里德度量标准)。

每个节点都维护一个存储桶阵列,每个存储桶包含适用于当前存储桶的节点地址。适当的“度”衡量ID的接近程度。考虑一下例子:

           0                              160
Node 1 ID: 1101000101011111101110101001010...
Node 2 ID: 1101011101011111101110101001010...
Node 3 ID: 1101000101011001101110101001010...

将XOR度量应用于节点#1,2,即(计算代表这些节点之间虚拟距离的数字),我们得到:

index - 012345678901234
xor   - 000001100000000... (the difference is in 5-th msb bit)
order - msb         lsb

将Xor度量应用于节点#1,3后,我们得到:

index - 012345678901234
xor   - 000000000000011... (the difference is in 13-th msb bit)
order - msb         lsb

显然,节点1更靠近节点3,因为它与节点1到节点2的距离具有较低有效位的差异。因此,从节点1的角度来看,它的邻居节点3进入第13节。 bucket(更高的索引意味着更接近的ID),节点2转到第5个桶,其中包含一组远离当前节点ID的5个MSB基数的节点。

这种数据结构允许每个节点以160个不同的距离知道它的周围环境。

回到您的示例,为了允许有效的地理位置查询,您需要将Kademlias XOR指标替换为普通的欧几里得指标。在这种情况下,您将ID作为3D或2D向量,不幸的是,由于Euclidian度量结果的浮点数不直接适用于此类算法,因此您需要将它们转换为离散的二进制数某种程度上与XOR功能类似。之后,找到节点的相邻节点是一项微不足道的任务。

希望这会有所帮助。哦顺便看看HyperDex,与euclidian度量密切相关的新的可搜索分布式数据存储可能会有所帮助......