fix: use accurate bucket logic #64
Conversation
|
@Stebalien What's the motivation on this i.e. what do we gain by not adding peers to the left ? |
|
We're adding peers from all buckets. The change is that, instead of adding peers from buckets from the right until we have enough peers, we just add all peers from buckets to the right, then sort them based on their distance to the target, then trim back down to K peers. This is strictly more accurate as all peers to the right are the same order of magnitude (same CPL). |
|
@Stebalien LGTM. Please can you merge this ? |
|
|
||
| for i := cpl + 1; i < len(rt.buckets) && pds.Len() < count; i++ { | ||
| pds.appendPeersFromList(rt.buckets[i].list) | ||
| if pds.Len() < count { |
There was a problem hiding this comment.
Yep. This is more accurate. And sorting happens later, I assume.
Stebalien
added
the
status/blocked
|
I'm blocking this on #66. Once we land that, we should store the pre-hashed peer ID in the routing table. Otherwise, if we're missing a single peer in the closest bucket, we'll have to hash all the peers to the right when sorting them. |
|
PR to store pre-hashed peerId and re-use them in |
Stebalien
removed
the
status/blocked
This reverts an optimization where we fudged the closer peers when returning responses to users when we were within a power of two to the target.
Stebalien
force-pushed
the
fix/accurate-buckets
branch
from
08f2efa
to
0a02da2
Compare
This reverts an optimization where we fudged the closer peers when returning responses to users when we were within a power of two to the target.