On Wed, Jun 10, 2009 at 4:04 PM, Florent Weber<florent.we...@gmail.com> wrote: > Hi Wang, > > If you want to use a faster algorithm than a DHT, you can use a > membership protocol to have a single search hop. > But in an high churn environment, the overhead can be high. > > You could have a look to Census for a very scalable membership protocol: > http://www.pmg.csail.mit.edu/pubs/census-usenix09-abstract.html > > Florent Weber
Thank you very much, Florent. The Census protocol is very interesting. It seems the results presented in the papers are excellent. Is there any available implementation of Census so that I can try it out? I visited your project home of CommonCensus at google code but got nothing yet. Thanks again. > > > 2009/6/9 Wang Danqi <beyond...@gmail.com>: >> Hi Kazuyuki, >> >> Thank you for your reply. I'd agree with you after I investigated a couple >> of papers. Your paper is very interesting and helpful. As presented in your >> paper, Chord, Pastry and Kademlia can be enhance to be very good in dealing >> peer churn. I also learned that the search hops could be well bounded, from >> both my simulation an other papers. >> >> I am doing same work to provide good content discovery service for P2P VoD >> systems. It seems that the industry, for example, PPLive in China, prefer to >> use centralized server-assisted approach to accomplish this task. I think >> the reason they don't use DHT is not because DHT is poor, but because DHT is >> complicated to implement and debug in real world, especially in such kind of >> latency intensive systems for comecial use. >> >> Now I doubt whether it is possible to come up with a content discovery >> algorithm that is faster and more robust than DHT, as the search hops of DHT >> is so well bounded, less than 4 with 10000 nodes in my simulation. Do you >> have any comments on this? >> >> I appreciate all your help. >> >> On Tue, Jun 9, 2009 at 12:18 AM, Kazuyuki Shudo <2...@shudo.net> wrote: >>> >>> Hi Wang, >>> >>> My results with Chord, Pastry and Kademlia are shown in this paper >>> (draft): >>> >>> "Churn Tolerance Improvement Techniques in an Algorithm-neutral DHT" >>> >>> http://www.shudo.net/publications/AIMS-2009-churn-resilience/shudo-AIMS-2009-churn-resilience.pdf >>> >>> The results are heavily dependent on the parameters of each routing >>> algorithms as you pointed out. It is difficult to derive general rules >>> but my feeling is that Chord with proper parameters is not so weak in >>> churn compared with Kademlia. It's just feeling. >>> >>> Kazuyuki Shudo 2...@shudo.net http://www.shudo.net/ >>> >>> >>> > Message-ID: >>> > <60b162860906072311l7942bc80qf8540f8751acb...@mail.gmail.com> >>> > From: Wang Danqi <beyond...@gmail.com> >>> > Date: Mon, 8 Jun 2009 14:11:08 +0800 >>> >>> > Hi all, >>> > >>> > I have implemented both Chord and Kademlia in my simulator according to >>> > the >>> > Chord paper in Sigcomm'01 and Kademlia paper in IPTPS'02 respectively. I >>> > ran >>> > a simulation with 1000 nodes and 1000 keys. The user arrival pattern >>> > follows >>> > a Poisson distribution and the lifespan is exponentially distributed. >>> > 1000 >>> > queries are generated for each key after every node gets online. >>> > However, I >>> > found the results from the two designs are significantly different. >>> > Chord >>> > performs much worse than Kademlia in terms of the fraction of successful >>> > queries, and it highly relies on the routing table refresh interval. Do >>> > you >>> > have any experience like this? I doubt whether Chord is so poor or I >>> > made >>> > some mistake in implementation. >>> > >>> > Thank you so much for your help. >>> > >>> > >>> > -- >>> > Best wishes, >>> > >>> > Wang Danqi >>> _______________________________________________ >>> p2p-hackers mailing list >>> p2p-hackers@lists.zooko.com >>> http://lists.zooko.com/mailman/listinfo/p2p-hackers >> >> >> >> -- >> Best wishes, >> >> Wang Danqi >> >> _______________________________________________ >> p2p-hackers mailing list >> p2p-hackers@lists.zooko.com >> http://lists.zooko.com/mailman/listinfo/p2p-hackers >> >> > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@lists.zooko.com > http://lists.zooko.com/mailman/listinfo/p2p-hackers > -- Best wishes, Wang Danqi _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
