Re: DHT traffic concerns

Quoting pwang708 <[email protected]> from ml.gnutella.dev-forum:
:> For instance, a "passive" UP can have a routing
:> table going to the depth of 5, flat, whereas a "passive leaf" could
:be limited
:> to a depth of 4.  That means 2^5 and 2^4 buckets of 20 nodes at most.
:
:In my opinion, 2^5 and 2^4 buckets of 20 nodes (contacts) are lots of
:contacts to maintain for passive nodes. What passive nodes need most
:is a small set of (reliable) nodes serving as gateways to the DHT.
:While larger routing table make queries go faster, but it create more
:maintenance traffic. Note that many of the passive nodes have short
:session time.

Agreed.  Maybe 1 bucket is enough after all, with alive pings and periodic
refresh, but with no splitting.  That should keep management traffic to
the minimum.

:> P.S: The DHT is currently suffering from a wrong publishing and
:replication
:> algorithm from LimeWire nodes.  I've identified problems and offered
:design
:> solutions for that. 
:
:What problem are you talking about?

Several problems actually:

* The expiration and republishing periods are way too small and cause too
  much republishing traffic.

* The presence of stale data in the DHT being persisted over and over.
  I have been witnessing that in my own lookups and in the traffic going
  on from my k-ball.

* The lack of usage of DHT STORE feedback (from the extended status code
  list I published), driving the recognition that something is NOT rare
  but actually quite popular.  I see too many STORE for some keys, way too
  many, and all these nodes must believe that what they publish is rare.
  See next point.

* The determination that something is rare and needs to be published is
  faulty.  The only real way to know something is rare is to try to publish
  it and see how many STORE_SC_FULL or STORE_SC_FULL_LOADED error
  conditions you get back.

Raphael