Re: DHT expiration questions

Quoting pwang708 <[email protected]> from ml.gnutella.dev-forum:
:A stale data item should not be permanently carried, unless some node
:keeps republishing it. Then it is not stale. :-) 

Unfortunately.  However, replicating (i.e. keeping alive) a dead alt-loc
(i.e. the creator is long gone or has changed IP address) is going to
use precious slots in the DHT keys: remember there are only 16 possible
slots at each node.

I believe the algorithm I have presented in my message is the best possible
under the circumstances.  Locally assigning a creation time at each node
is the same as we have today with the download mesh.  And it results
in stale addresses being propagated forever in the mesh.

:The default republish time is 30 minutes. The republish time could be
:smaller if the DHTvalue was published to less than 20 node last time. 
:
:(locationCount * DatabaseSettings.VALUE_REPUBLISH_INTERVAL.getValue())
:                    / KademliaSettings.REPLICATION_PARAMETER.getValue());

I don't understand what the above computes, but in any case, republishing
every 30 minutes is INSANE!  Do you realize the amount of traffic this
generate in the network?  You have to perform a node lookup for the key,
resulting in 20 RPCs at least, store the value using another batch of
20 RPCs, and then repeat that every 30 minutes for every value you
wish to publish?

Just plain INSANE.  Please fix this ASAP in all LimeWire nodes or you're
going to cause too much DHT traffic.

Publishing PROX values every 2 hours is OK because you have at most 3 such
proxies.  Publishing ALOC every 12 hours is also OK.  These are the
settings GTKG is going to use.  Publishing something every 30 minutes is
INSANE.

Of course, you have to set expiration intervals accordingly.  To avoid
race conditions, they must be greater than republishing intervals.  That's
why GTKG will use 13 hours for ALOC and 3 for PROX.

My node is already sending out 8 MiB of DHT traffic per hour just to reply
to FIND_VALUE, FIND_NODE and STORE requests.  (I do not publish nor replicate
yet, because I wanted to think about what I would do first)

That amounts to 2,27 KiB/s of outgoing UDP traffic that is just not
available for uploading.  I bet the frequent publishing is the cause of
much of that traffic.  Just like frequent requerying melted Gnutella in
the old days, frequent republishing is going to kill the DHT.

Offhand, LimeWire needs to understand the STORE_SC_FULL and its cousin
STORE_SC_FULL_LOADED return codes.  I had recently a store EMA load of
32.45! Yes, that's right, a sustained average of 32+ STORE requests per
minute for a key, storing ALOC.

This shows the algorithm to determine whether something is "rare" is
faulty without getting feedback from the DHT.  Here, if you handle the
errors correctly, the publishing nodes will stop thinking their value is
rare and will republish less often.  The correction must be random, so
as to not go to the other extreme where nobody would republish anymore,
leading to a missing key. Also hysteresis is required to avoid jumping
in and out for no reason.

:As far as I understand, only the root node (whose ID is the closest to
:the key) forwards data to new replica roots (whose ID is among the 20
:closet ones). So a new node joining the neighborhood becomes the root,
:then the data will expire later what one hour. So there is a chance
:that data being replicated over and over. 

Under the scheme I'm going to implement in GTKG, only nodes who have
been seeing a STORE from the creator (hence holding an "original" value
as opposed to a "copy") will replicate the data to peers.  A peer getting
a "copy" will store it but NEVER replicate it.  This should keep the
replication traffic to a reasonable level, as well as avoid forever-living
dead ALOC and PROX. Naturely, if one of the peers in the k-ball replicates
first, GTKG will not re-replicate before the next hour.

Raphael