Re: Why competing Gnutella clients help LimeWire

I wrote:

>>> The main thing to note is how we handle k-buckets doesn't matter
to the over all success of the protocol (just the efficiency), as long
as any FIND* message returns nodes at least one bit closer to the query.

> --- In [email protected], "Zlatin Balevsky" <zlatinb@> wrote:

>> Really?  I remember we went to great lengths to emulate bucket
behavior through Patricia.  We have added some code that will let us
do some advanced statistical measurements that will give a lot of
insight into how Kademlia functions.

If you google the paper I cited, you will find some interesting
information.  The paper support (incited) my statements.

"http://www.google.ca/search?q=Improving+Lookup+Performance+over+a+Widely-Deployed+DHT"

--- In [email protected], "rogerkapsi" <roger@...> wrote:

> That's pretty obvious no? The k-buckets are important for two things
though. For one they improve the resistance against malicious Nodes. 
Once a k-bucket is full and the Tree has reached its max depth there's
no easy way for malicious Node to be added to the Route Table. Second,
the k-buckets ensure that every Node has good but not too much
knowledge of the DHT.

I am not so sure about these statements.  Specifically the attacks. 
The long uptime nodes help protect against churn.  A malicious node
can have long up time.  One attack stated is to have a lot of long
uptime nodes disappear at the same time.  The hope is to fragment the
network.

An attack I haven't seen stated elsewhere is to return fake nodes very
close to the target.  These fake nodes can further relay and then not
return a value (for FIND_VALUE).  If the "log N" value is 5 hops,
having several corrupt nodes at the first, or second hop can send a
lookup down the wrong path.  This just has to be 'alpha' of them.  The
next to last nodes have to have 'k' dead end values to stop the search.

I think Kademlia hasn't been deployed widely and isn't as popular as
GNET, so there are not so many attacks against it.  I find that as a
major criticism of papers like this,

"http://www.aqualab.cs.northwestern.edu/publications/YQiao06SUO.pdf"

> It's a bit hard to implement the Route Table without k-buckets. As
for FIND* operations we (LimeWire) do as if there are no k-buckets.

That is my main point.  The lookups don't depend on k-buckets at all,
so how you implement them is not *critical* to the success of the
protocol.  The k-buckets just provide a very efficient way to return
values for a lookup.

fwiw,
Bill Pringlemeir.