feat(core-p2p): implement throttling on outgoing p2p communication #3170
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
vasild
requested review from
air1one,
faustbrian,
kristjank and
spkjp
as code owners
Use the rate limiter in reverse to stop ourselves from sending too many requests to a given peer that could possibly trigger their protection and result in banning us. We use the default configuration for rate limits. So this will work as long as the peer is using the same software and has not changed his config or has made it more liberal. If the peer has made his limits more restricted, then we could still trigger their protection. A more robust solution would be to negotiate the rate limits at peer handshake and then obey different limits for each peer.
vasild
force-pushed
the
feat-p2p-outgoing-throttle
branch
from
fc5ce29
to
c0123ce
Compare
Codecov Report
@@ Coverage Diff @@
## develop #3170 +/- ##
===========================================
+ Coverage 65.61% 65.61% +<.01%
===========================================
Files 426 426
Lines 11940 11946 +6
Branches 1597 1597
===========================================
+ Hits 7834 7838 +4
- Misses 4073 4075 +2
Partials 33 33
Continue to review full report at Codecov.
|
spkjp
approved these changes
Oct 29, 2019
There was a problem hiding this comment.
Seems to work as advertised:
17|ark-relay | [2019-10-29 15:26:53.407] DEBUG: Downloading blocks in chunks: [4045974, ..]
17|ark-relay | [2019-10-29 15:26:53.408] DEBUG: Throttling outgoing requests to 209.50.61.104/p2p.peer.getBlocks to avoid triggering their rate limit
17|ark-relay | [2019-10-29 15:26:53.469] INFO : 80.211.177.153 has downloaded 0 blocks from height 4,045,974
17|ark-relay | [2019-10-29 15:26:53.740] INFO : 142.44.253.192 has downloaded 0 blocks from height 4,045,974
17|ark-relay | [2019-10-29 15:26:54.546] INFO : 80.211.177.153 has downloaded 0 blocks from height 4,045,974
17|ark-relay | [2019-10-29 15:26:54.552] INFO : 35.222.188.169 has downloaded 0 blocks from height 4,045,974
17|ark-relay | [2019-10-29 15:26:54.805] INFO : 104.237.9.72 has downloaded 0 blocks from height 4,045,974
17|ark-relay | [2019-10-29 15:26:55.738] ERROR: Could not download blocks [4045974, ..] from any of 27 peers. Last attempt returned 0 blocks from peer 94.177.218.138:4002.
17|ark-relay | [2019-10-29 15:26:55.742] INFO : Could not download any blocks from any peer from height 4045974
17|ark-relay | [2019-10-29 15:26:55.743] DEBUG: event 'NOBLOCK': {"syncWithNetwork":"downloadBlocks"} -> {"syncWithNetwork":"syncing"} -> actions: [checkLastDownloadedBlockSynced]
17|ark-relay | [2019-10-29 15:26:55.744] DEBUG: Queued chunks of blocks (process: 0)
17|ark-relay | [2019-10-29 15:26:55.745] DEBUG: event 'NOTSYNCED': {"syncWithNetwork":"syncing"} -> {"syncWithNetwork":"downloadBlocks"} -> actions: [downloadBlocks]
17|ark-relay | [2019-10-29 15:26:55.746] DEBUG: Downloading blocks in chunks: [4045974, ..]
17|ark-relay | [2019-10-29 15:26:55.747] DEBUG: Throttling outgoing requests to 51.158.164.99/p2p.peer.getBlocks to avoid triggering their rate limit
17|ark-relay | [2019-10-29 15:26:55.754] INFO : 142.44.253.192 has downloaded 0 blocks from height 4,045,974
17|ark-relay | [2019-10-29 15:26:55.772] INFO : 50.3.232.142 has downloaded 0 blocks from height 4,045,974
17|ark-relay | [2019-10-29 15:26:55.945] INFO : 104.237.9.72 has downloaded 0 blocks from height 4,045,974
17|ark-relay | [2019-10-29 15:26:55.969] INFO : 35.222.188.169 has downloaded 0 blocks from height 4,045,974
17|ark-relay | [2019-10-29 15:26:56.223] INFO : 50.3.247.191 has downloaded 0 blocks from height 4,045,974
ghost
deleted the
ghost
mentioned this pull request
faustbrian
pushed a commit
that referenced
this pull request
Feb 12, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Use the rate limiter in reverse to stop ourselves from sending too
many requests to a given peer that could possibly trigger their
protection and result in banning us.
We use the default configuration for rate limits. So this will work as
long as the peer is using the same software and has not changed his
config or has made it more liberal. If the peer has made his limits
more restricted, then we could still trigger their protection.
A more robust solution would be to negotiate the rate limits at peer
handshake and then obey different limits for each peer.
Summary
Checklist