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.
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
[Networking] GossipSub iWant Flooding Mitigation #4574
[Networking] GossipSub iWant Flooding Mitigation #4574
Changes from 1 commit
0093a47
41ef40b
5cf8b9d
322aee5
03a4423
85f63c6
3e99842
2e6c88a
b745ea3
acf9486
3ff2eaf
eccb7a1
38d5caf
704a20d
26a7159
c815a12
9c09799
d9c7970
bb87e90
e3f7fb8
3b7aa43
7721c00
48b8fa1
c0b999a
848a708
efdeb97
c9e1dab
fb521fc
ba7406e
6d226ad
acb84a0
4090cb0
45e77ff
a6d9eaa
130fc6b
e249547
1f71d13
eb6434d
e530edc
897cb98
96c1d4f
2e3a710
a865809
88ab754
8150c52
367b94c
37cfa4d
7c1d963
a4fcdb5
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Check failure on line 141 in network/netconf/flags.go
GitHub Actions / Lint (./)
Check failure on line 141 in network/netconf/flags.go
GitHub Actions / Lint (./)
Check failure on line 141 in network/netconf/flags.go
GitHub Actions / Lint (./)
Check failure on line 141 in network/netconf/flags.go
GitHub Actions / Lint (./)
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.
This method is better to also receive the
peer.ID
of the sender ofiWants
and use thepeer.ID
in all the logs and errors generated by the method.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.
848a708
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.
This looks fine and is a fail-safe approach, i.e., we don't want to continue the execution if we cannot sample a control message properly. But please note that whatever error a worker
processFunc
returns will result in the node to crash, hence we may need to be more cautious on what to return as error and what to log.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.
Before returning the method, please add a debug level log logging the previous log's content as well as the
duplicate
andcacheMisses
counters. It would be instrumental for forensics.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.
efdeb97
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 have observed that the current implementation of
getCtrlMsgCount
does not meet our specific requirements. Instead of returning the total count of control message types within the RPC, it should provide the total number of message-ids for a specific message type. Take theiHave
message as an example; an RPC may contain severaliHave
messages, each with a distinct set of message-ids.This situation creates a problem, particularly in the evaluation of
count > validationConfig.HardThreshold
. In this context,count
is representative of the total number ofiHave
messages, each containing a distinct message-id count, whereasvalidationConfig.HardThreshold
denotes the total number ofiHave
message-ids. Consequently, the condition within theif
statement is often incorrectly assessed as false in many cases. This inconsistency must be addressed to align the logic with our intended functionality.I kindly request that you refactor this function to accurately reflect the message-id count for the given message type, aligning with the discussion found at this GitHub comment. Thank you.
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.
This is covered in the follow up PR that adapts this strategy to the other control messages #4642