-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement resource discovery by "Flood with Random Walk" algorithm #1711
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest to use a counter TTL instead of timestamp.
Generally speaking, relying on timestamps in a distributed network is never a great approach, since it relies on local node clocks to be synchronized.
While we're considering having nodes use NTP, we should not rely on it if not necessary.
Additionally, using a counter allows to better control the maimum number of hops the request will go through, regardless of the latency.
- Use request_block_by_height to initialize a presync procedure - Update default hops_limit to 128 - Update DEFAULT_CERT_CACHE_EXPIRY to 1min - Fix the condition for detecting sync target is reached
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Resolves #1528
Resolves #1722
Acceptance criteria:
GetBlocks
message flow works properly as usual. It should not triggerflood_request
GetData/GetResource
usesflood_request
to retrieve a resource (block/transaction) from a distant peer.GetData/GetResource
limits aflood_request
byhops_limit
setting.certificate cache
is cleaned up properlyMempool
message returns mempoolNB: Testing the impl of this approach revealed a race condition that was (most probably) previously happening too. It'll be addressed with #1722