Faulty node lookup in LimeWire

Here are more statistics about "foreign storage":

I ran a node for 20 hours during which I got 4475 keys stored.
Out of these, only 1683 fell within my k-ball.

That means 62% of all STORE requests come to my node when it is not
the ideal target for the key, and actually not within the k-ball for
that key.

Gtk-gnutella implements the DHT expiration policy I have published earlier
on the GDF, so these "foreign keys" expire fairly quickly.  However, they
cause a lot of waste: think about all this undue traffic at my node that is
useless because the stored values are quickly discarded; think about the
publishing traffic spent by the publishing node that is wasted (the lifetime
of these foreign keys is a few minutes).

Given GTKG is not publishing to the DHT yet, these faulty publishing are
entirely due to the behaviour of LimeWire.  This means any traffic analysis
done by inspecting node traffic is somehow tainted.

Furtheremore, it could explain why some lookups do not return values: if they
are published in foreign places, there is no way to find them when the correct
lookup is initiated.

Raphael

P.S: I'm NOT considering value caching here.  I occasionally see it happen,
but usually it is for keys that belong to my k-ball, so they are not so
foreign.  My usual k-ball frontier is 14 common leading bits (furthest
node in the k-ball).