使用哪种 DHT 算法（如果我想加入两个单独的 DHT）？
我一直在研究一些 DHT 系统，特别是 Pastry 和 Chord。我读到过一些关于 Chord 对流失反应的担忧，但我相信这对于我手头的任务来说不会成为问题。我正在实现某种社交网络服务，该服务不依赖于课程项目的任何中央服务器。我需要 DHT 来进行查找。
现在我一开始并不知道网络中的所有服务器。正如我所说，没有主跟踪服务器。它的工作方式是这样的：每个客户端都有三个专用服务器。这三台服务器都有客户端的配置文件，它的墙，它的个人信息，被复制。只有当用户添加朋友（输入客户端地址）时，我才了解其他服务器组。因此，我会在两组（每组三台服务器）上创建两个单独的 DHT，当它们彼此成为好友时，我想加入这些 DHT。我希望始终如一地做到这一点。我没有太多时间来熟悉这些协议，所以我想知道如果我想加入两个独立的 DHT，哪一个更好？
I've been looking into some DHT systems, specially Pastry and Chord. I've read some concerns about Chord's reaction to churn, though I believe that won't be a problem for the task I have at hands. I'm implementing some sort of social network service that doesn't rely on any central servers for a course project. I need the DHT for the lookups.
Now I don't know of all the servers in the network in the beginning. As I've stated, there's no main tracker server. It works this way: each client has three dedicated servers. The three servers have the profile of the client, and it's wall, it's personal info, replicated. I only get to know about other group of servers when the user adds a friend (inputing the client's address). So I would create two separate DHTs on the two groups of three servers and when they friend each other I would like to join the DHTs. I would like to this consistently. I haven't had a lot of time to get all that familiar with the protocols, so I would like to know which one is better if I want to join the two separate DHTs?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
分布式哈希表旨在自动处理查找存储给定数据的节点的问题。因此，在 DHT 设计理念中，您不会有一个用于配置文件、墙等的专用服务器...您将为每个服务器拥有一个专用的数据标识符，并且 DHT 将处理将数据放置在活动服务器之间并为给定的数据找到正确的服务器。
Pastry 和 Chord 在功能方面非常相似，主要区别在于它们处理邻居集和路由的方式。我不清楚对于此类应用程序，其中一个会比另一个更好。
一篇很好的技术比较论文是性能与成本框架如果您确实需要详细信息，请评估流失情况下的 DHT 设计权衡 (PDF)，来自 Infocom 2005。
Distributed hash tables are designed to automatically handle the problem of finding a node that stores a given piece of data. So, in the DHT design philosophy, you wouldn't have a dedicated server for the profile, wall, etc... you'd have a dedicated data-identifier for each of those and the DHT would handle placing the data amongst active servers and finding the correct server for a given piece of data.
Pastry and Chord are pretty similar in terms of functionality and differ mostly in how they handle neighbor sets and routing. It's not clear to me that one would be better than the other for this sort of application.
A good technical comparison paper is A performance vs. cost framework for evaluating DHT design tradeoffs under churn (PDF), from Infocom 2005, if you really want details.