Skip to content
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

Move syncer block download retries inside the peer set #3235

Closed
teor2345 opened this issue Dec 15, 2021 · 1 comment
Closed

Move syncer block download retries inside the peer set #3235

teor2345 opened this issue Dec 15, 2021 · 1 comment
Labels
A-network Area: Network protocol updates or fixes C-security Category: Security issues I-slow Problems with performance or responsiveness

Comments

@teor2345
Copy link
Collaborator

Motivation

In PR #3191, we add a yield to syncer block download retries, so that:

  • we're more likely to choose a different peer, and
  • any notfound inv entries win the race to the PeerSet

But if we did block download retries within the PeerSet, we could always choose different peers. This would also help us limit retries to the number of available peers.

This prevents a single failing peer from monopolising all peer requests.

Designs

Move the inner block download RetryLimit(2) from the syncer to the PeerSet:

  • choose different peers, if we have at least two available
  • mark them both unready
  • send the request to the first peer
  • if the first request fails, send the request to the second peer
  • if the first request succeeds, cancel the second peer and make it ready again (needs tests)

After this change, gossiped blocks would also get retries, but that's probably ok.

Related Work

@teor2345 teor2345 added S-needs-triage Status: A bug report needs triage P-Low C-security Category: Security issues I-slow Problems with performance or responsiveness A-network Area: Network protocol updates or fixes labels Dec 15, 2021
@teor2345
Copy link
Collaborator Author

This is obsoleted by the notfound changes in #2156

@mpguerra mpguerra removed the S-needs-triage Status: A bug report needs triage label Sep 28, 2022
@mpguerra mpguerra closed this as not planned Won't fix, can't repro, duplicate, stale May 11, 2023
mergify bot pushed a commit that referenced this issue May 23, 2023
* ZIPs were updated to remove ambiguity, this was tracked in #1267.

* #2105 was fixed by #3039 and #2379 was closed by #3069

* #2230 was a duplicate of #2231 which was closed by #2511

* #3235 was obsoleted by #2156 which was fixed by #3505

* #1850 was fixed by #2944, #1851 was fixed by #2961 and #2902 was fixed by #2969

* We migrated to Rust 2021 edition in Jan 2022 with #3332

* #1631 was closed as not needed

* #338 was fixed by #3040 and #1162 was fixed by #3067

* #2079 was fixed by #2445

* #4794 was fixed by #6122

* #1678 stopped being an issue

* #3151 was fixed by #3934

* #3204 was closed as not needed

* #1213 was fixed by #4586

* #1774 was closed as not needed

* #4633 was closed as not needed

* Clarify behaviour of difficulty spacing

Co-authored-by: teor <teor@riseup.net>

* Update comment to reflect implemented behaviour

Co-authored-by: teor <teor@riseup.net>

* Update comment to reflect implemented behaviour when retrying block downloads

Co-authored-by: teor <teor@riseup.net>

* Update `TODO` to remove closed issue and clarify when we might want to fix

Co-authored-by: teor <teor@riseup.net>

* Update `TODO` to remove closed issue and clarify what we might want to change in future

Co-authored-by: teor <teor@riseup.net>

* Clarify benefits of how we do block verification

Co-authored-by: teor <teor@riseup.net>

* Fix rustfmt errors

---------

Co-authored-by: teor <teor@riseup.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-network Area: Network protocol updates or fixes C-security Category: Security issues I-slow Problems with performance or responsiveness
Projects
None yet
Development

No branches or pull requests

2 participants