Which DHT algorithm to use (if I want to join two separate DHTs)?

Question

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?

Answer 1

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.