-
Notifications
You must be signed in to change notification settings - Fork 2k
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
[CHIA-1829] don't drop outgoing response messages #18990
Merged
Merged
+213
−63
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
arvidn
changed the title
never rate limit outgoing response messages
[CHIA-1829] never rate limit outgoing response messages
Dec 4, 2024
arvidn
added
the
Fixed
Required label for PR that categorizes merge commit message as "Fixed" for changelog
label
Dec 4, 2024
arvidn
force-pushed
the
ratelimit-drop-msg
branch
from
December 5, 2024 21:50
fc89378
to
6204787
Compare
arvidn
changed the title
[CHIA-1829] never rate limit outgoing response messages
[CHIA-1829] don't drop outgoing response messages
Dec 5, 2024
arvidn
force-pushed
the
ratelimit-drop-msg
branch
from
December 5, 2024 22:07
6204787
to
6b02e55
Compare
arvidn
force-pushed
the
ratelimit-drop-msg
branch
from
December 6, 2024 12:10
6b02e55
to
25048ad
Compare
arvidn
force-pushed
the
ratelimit-drop-msg
branch
from
December 6, 2024 15:53
25048ad
to
10e6e76
Compare
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
arvidn
force-pushed
the
ratelimit-drop-msg
branch
from
December 6, 2024 23:58
10e6e76
to
b751817
Compare
…cks, RejectBlock, RejectBlocks). Instead, disconnect any peer sending unsolicited response blocks
arvidn
force-pushed
the
ratelimit-drop-msg
branch
from
December 7, 2024 10:30
b751817
to
d8756b3
Compare
Pull Request Test Coverage Report for Build 12212149266Details
💛 - Coveralls |
aqk
approved these changes
Dec 11, 2024
almogdepaz
approved these changes
Dec 11, 2024
emlowe
approved these changes
Dec 11, 2024
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.
nice analysis
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.
Purpose:
With regards to long sync, there are two serious issues with the current rate limits.
1. send- vs. receive limits
request_blocks
has a rate limit of 500 messages / minute andrespond_blocks
has a rate limit of only 100 messages / minute. This discrepancy was probably an oversight, as it doesn't make sense to allow responses at a lower rate than request.Additionally, all outgoing messages are subject to a reduction of limit to 30%, so the effective limit for response messages is much lower than the corresponding request message. This was probably an attempt to avoid exceeding limits because of phase shifted 1-minute windows. What appears to staying within the limits on the sender may exceed the limits on the receiver, if the windows overlap in the right way.
This reduction causes the peer serving blocks to hit its send rate limit (of response messages) long before the requesting peer hits its rate limit for request messages. Since #18907 landed, this problem can be seen in the logs, quite often. When the response message is dropped, the requesting peer waits for 30 seconds before timing out and banning the other peer. This significantly slows down long sync.
The issue of sending
request_blocks
at too high rate, causing disconnects, was attempted to be addressed in #18729. Not only did this patch make it clear just how rate limited long-sync is, but it turned out this wasn't enough. Because of the second issue, described below, to make the request pacing work well, it would have to be even more complex.2. overall bytes limit
Even though the
respond_blocks
message has a limit of 250 MB / minute, there's an independent limit of the combined sizes of all non-TX messages). This limit is just 100 MB / minute. This was probably an oversight. It appears as if the intention was to limitrespond_blocks
to the higher value, but it never takes effect. Additionally, both of these limits are also subject to the upload rate factor of 30%, so the effective limit of all (non-TX) messages sent is just 30 MB/minute, or 512 kiB/s.This change
This change removes the rate limit entirely for the following messages:
Implemented here and here.
To prevent abuse, we also need to disconnect any peer sending these messages unsolicited. Implemented here.
This change is essentially backwards compatible because the response messages are effectively rate limited by the corresponding request messages, and if you exceed the rate limit, disconnecting (without banning) is still a better outcome than waiting 30 seconds and then disconnect and ban the peer.
Previous incoming response limits:
With this patch, if you send the maximum number of request_blocks, 150 you may receive 150 respond_blocks and disconnect the peer. The current behavior is that you receive 30 respond_blocks, wait 30 seconds and then ban the peer.
Current Behavior:
RespondBlock, RespondBlocks, RejectBlock, RejectBlocks are subject to unreasonably low rate limits, causing issues syncing.
New Behavior:
RespondBlock, RespondBlocks, RejectBlock, RejectBlocks are not subject to any rate limits other than the implied rate limit of the corresponding request message.
Peers sending unsolicited responses are banned.
Testing Notes:
I've been running a node on testnet11 to ensure I no longer drop respond_blocks messages.