Sorry to catch in, see inline. Best Regards, Song Yongchao
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Pub > Sent: Thursday, January 10, 2008 4:50 PM > To: theory and practice of decentralized computer networks > Subject: Re: [p2p-hackers] SOA dedicated DHT > > Hello, > > These overlays work well for a reasonable amount of key (<10.000), but > crash more or less (java exceptions, cpu/memory explosion, freeze, ....) > when inserting millions of key per node. In theory, all overlays are > designed to support millions of entries, but in practice, there are > never tested. The authors just supposed that if it works with 10.000 > keys, then it works for 10.000.000 keys. But it's rarely the case. This makes me worry about the spam attack in the P2P overlay very much. Some malicious or badly behaving peer may put a lot of useless resource records to the overlay, which may make the p2p overlay go down. Attackers can also choose specific destination ID within the ID space to put spams, which will make the specific peer fail. > And then CPU will become the issue (XML parsing, message marshalling, > ...), and then memory again, and so on .... :-) > > > > I have measured performance of Overlay Weaver and Bamboo and noticed > > that other operations (e.g. XML processing) than DHT operations took a > > large part of the measured time. > > > Yes, I observed the same behavior on the overlays I've tested. If you have the estimated compared proportion of the measured time for DHT operations and other operations within a put transaction, I have interests in that. > 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
