-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
implement a proper relay v2 search strategy #9257
Copy link
Copy link
Open
Labels
P3Low: Not priority right nowLow: Not priority right noweffort/daysEstimated to take multiple days, but less than a weekEstimated to take multiple days, but less than a weekexp/wizardExtensive knowledge (implications, ramifications) requiredExtensive knowledge (implications, ramifications) requiredkind/enhancementA net-new feature or improvement to an existing featureA net-new feature or improvement to an existing featuretopic/libp2pTopic libp2pTopic libp2p
Description
Metadata
Metadata
Assignees
Labels
P3Low: Not priority right nowLow: Not priority right noweffort/daysEstimated to take multiple days, but less than a weekEstimated to take multiple days, but less than a weekexp/wizardExtensive knowledge (implications, ramifications) requiredExtensive knowledge (implications, ramifications) requiredkind/enhancementA net-new feature or improvement to an existing featureA net-new feature or improvement to an existing featuretopic/libp2pTopic libp2pTopic libp2p
Description
Our current relay search is pretty bad.
It just constantly poll our K cluster with some exp-backoff.
The goal of this is to avoid convergence on a few nodes and spread the relaying load more or less evenly on all reachable dhtservers.
However the actual strategy we were supposed to implement is an outward search until success. If no nodes in our K cluster support relaying, it probably will never change.
Maybe a random polling of the DHT is not that bad after all ?
API
Currently this is implemented with a long running task, this would need to be rewriten to be statefull and executing in the libp2p callback.