Interesting! My first question would be: why start out with a DHT, why not keep things simple and start with a simple central server to get the overall usability sorted out, and then go to a DHT later? It's a very hard technical problem to solve; I'd just question whether that's necessary.
As for the core networking layer, I'd suggest putting a lot of thought into your NAT penetration strategy up front. It's at least as hard a problem as the DHT itself, and it has huge ramifications on the protocol design. Does anybody know if there are any good libraries for this yet? I know the P2P-SIP guys have been talking about this for *years* now with ICE -- has anything come to fruition yet? -david Emmanuel Benazera wrote: > Hi all, > > I'm the lead of the Seeks project (http://www.seeks-project.info), an open > source > design and software for enabling social websearch. The core idea is to work > on top > of existing search engines and to regroup users whose queries are similar so > they can > share both the query results and their experience on these results. > The system does more than this, but this is not the point here. > > The regrouping of users on the basis of their queries uses a DHT and a custom > LSH (locality sensitive hashing) scheme. I am in the final stages of > implementing the > routing layer of the DHT. It is based on the Chord protocol, protobuffers, and > UDP packets. > > Seeks development requires advanced skills in many areas of computer science. > Being mostly > an AI guy, at this point I'm seeking advice from p2p experts and > practitioners, and more > precisely on the following two points: > > - Every of the DHT machines supports a variable number of virtual nodes. > Therefore our > DHT key generation scheme uses: 48bit of the MAC address and 112 random bits > (not from > a 'strong' generator), that are then hashed with RIPEMD-160 to get the 160bit > key. > With no huge expectations on the number of nodes in the near future, does > this seem a robust > scheme to you ? My understanding is that uniformity should be around that of > the RIPEMD-160 > itself. > > - Given the objectives of the project, are there some problems and not so > well-known > caveats I should be aware of when using a Chord-like protocol ? I'm aware of > the > general litterature on Chord (optimal routing, rotating virtual nodes, > deBruijn graphs, > ...). Should I look into something in particular ? > > Any other comment, criticism and other advices or speculations are welcome, > as we > expect the DHT to reach the main trunk in a (finite) number of weeks now :) > > For those interested in the project at large, here is more information: > - technical overview: http://seeks-project.info/wiki/index.php/Technical > - a manifesto: http://www.seeks-project.info/manifesto.html > - a list of public (standalone, metasearch) nodes you can use already: > http://seeks-project.info/wiki/index.php/List_of_Web_Seeks_nodes > - documents: http://seeks-project.info/wiki/index.php/Documents > > Source code is available from our git repository on Sourceforge, the DHT > remains > under heavy development with several daily commits, but is nevertheless > accessible > from the 'dht' branch. > > Thanks, > > Emmanuel Benazera > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
