Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Do not ban peers for sending multiple valid requests #8325

Merged
2 commits merged into from
Mar 12, 2021

Conversation

bkchr
Copy link
Member

@bkchr bkchr commented Mar 11, 2021

We introduced banning of peers who spam us with the same request (more
than 2 times). However, we missed that it is completely legal to send
the same request multiple times as long as we did not provide any
answer. An example for that is the justification request. This request
is send multiple times until we could fetch the justification from one
of our peers. So, the solution to this problem is to tag requests as
fulfilled and to start counting these fulfilled requests. If the number
is higher than what we allow, the peer should be banned.

Thank you for your Pull Request!

We introduced banning of peers who spam us with the same request (more
than 2 times). However, we missed that it is completely legal to send
the same request multiple times as long as we did not provide any
answer. An example for that is the justification request. This request
is send multiple times until we could fetch the justification from one
of our peers. So, the solution to this problem is to tag requests as
fulfilled and to start counting these fulfilled requests. If the number
is higher than what we allow, the peer should be banned.
@bkchr bkchr added A0-please_review Pull request needs code review. B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. labels Mar 11, 2021
@bkchr bkchr requested review from andresilva and arkpar March 11, 2021 10:46
@@ -212,6 +228,21 @@ impl<B: BlockT> BlockRequestHandler<B> {
max_blocks,
)?;

// If any of the blocks contains nay data, we can consider it as successful request.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// If any of the blocks contains nay data, we can consider it as successful request.
// If any of the blocks contains any data, we can consider it as successful request.

@arkpar
Copy link
Member

arkpar commented Mar 12, 2021

We introduced banning of peers who spam us with the same request (more
than 2 times). However, we missed that it is completely legal to send
the same request multiple times as long as we did not provide any
answer.

You mean it is legal to send the same request multiple times when we provide an empty answer?

The sync protocol requires that each request will either be answered (possible with empty block list), or the connection to be terminated.

@bkchr
Copy link
Member Author

bkchr commented Mar 12, 2021

You mean it is legal to send the same request multiple times when we provide an empty answer?

Yes. This for example happens for the justification request.

@andresilva
Copy link
Contributor

bot merge force

@ghost
Copy link

ghost commented Mar 12, 2021

Trying merge.

@ghost ghost merged commit 97ecd62 into master Mar 12, 2021
@ghost ghost deleted the bkchr-fix-block-message-ban branch March 12, 2021 11:13
KalitaAlexey pushed a commit to KalitaAlexey/substrate that referenced this pull request Jul 9, 2021
We introduced banning of peers who spam us with the same request (more
than 2 times). However, we missed that it is completely legal to send
the same request multiple times as long as we did not provide any
answer. An example for that is the justification request. This request
is send multiple times until we could fetch the justification from one
of our peers. So, the solution to this problem is to tag requests as
fulfilled and to start counting these fulfilled requests. If the number
is higher than what we allow, the peer should be banned.
jordy25519 pushed a commit to cennznet/substrate that referenced this pull request Sep 17, 2021
We introduced banning of peers who spam us with the same request (more
than 2 times). However, we missed that it is completely legal to send
the same request multiple times as long as we did not provide any
answer. An example for that is the justification request. This request
is send multiple times until we could fetch the justification from one
of our peers. So, the solution to this problem is to tag requests as
fulfilled and to start counting these fulfilled requests. If the number
is higher than what we allow, the peer should be banned.
This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A0-please_review Pull request needs code review. B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants