-
Notifications
You must be signed in to change notification settings - Fork 186
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
GossipSub v1.2: IDONTWANT control message and priority queue. #553
Conversation
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.
So far looking good overall.
However, I think using a slice to back the queue is problematic at many levels as it might leak space with a growing array, and also hang on to too much space.
I would very much prefer using a dequeue for this.
The unused space will be freed eventually https://stackoverflow.com/a/26863706 |
I'm not really sure if we need dfd81e8 or not. I guess adding a non-standard flag to |
Yeah, let's not break compatibility with existing code, we don't need it. Any progress other than that? |
I haven't implemented the second half. Does the first half looks good to you? |
yes, looks reasonable so far. |
@vyzo I finished everything already. Sorry for the delay. I was in vacation and was a bit busy lately. Thank you for your patience. |
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.
Generally looks good, but lets make the counter clear less aggressive.
The message ids from IDONTWANT can be very large, so hashing it before keeping it in memory quite makes sense. The same thing is already implemented in nim-libp2p vacp2p/nim-libp2p#1090 |
sure, but it needs to be cleared, otherwise its memroy leak and dos waiting to happen. Or at best the feature breaks itself for long running nodes. I suggest for each IDW keep a counter of how many heartbeats it survived, and after 3 (to match the IHAVE ads) it should be cleared. |
@vyzo It's all done. Sorry for the delay. |
ok, can you rebase on master? |
11fed73
to
d44d15a
Compare
@vyzo wondering if this PR ready to be merged or are you waiting for anything to be fixed/addressed? This seems to improve bandwidth usage and we want to take advantage of that. |
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 think in general it looks good, but i do want to do another pass.
In the meantime:
- can you bump the version to 1.2
- can you add a feature test to not send IDONTWANT if the other side doesnt support it?
I will also invoke @Stebalien for review.
Haven't looked at the PR in detail, but will give it a try tomorrow. |
Since we want to implement a priority queue later, we need to replace the normal sending channels with the new smart structures first.
UrgentPush allows you to push an rpc packet to the front of the queue so that it will be popped out fast.
Most importantly, this commit adds a new method called PreValidation to the interface PubSubRouter, which will be called right before validating the gossipsub message. In GossipSubRouter, PreValidation will send the IDONTWANT controll messages to all the mesh peers of the topics of the received messages.
When receiving IDONTWANTs, the host should remember the message ids contained in IDONTWANTs using a hash map. When receiving messages with those ids, it shouldn't forward them to the peers who already sent the IDONTWANTs. When the maximum number of IDONTWANTs is reached for any particular peer, the host should ignore any excessive IDONTWANTs from that peer.
If the messages IDs received from IDONTWANTs are older than 3 heartbeats, they should be removed from the IDONTWANT cache.
Rather than keeping the raw message ids, keep their hashes instead to save memory and protect again memory DoS attacks.
@vyzo I didn't get any error with FuzzAppendOrMergeRPC, did you?
|
thats a flake then. |
done |
CI failures - seems like a faulty commit. |
This reverts commit f141e13.
@Stebalien @vyzo I think it's all done |
running the CI, will merge once it greens. |
should I squash the fix-up commits? |
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.
Looks good! Thank you!
no need, I will squash merge anyway |
Sending IDONTWANT
Handling IDONTWANT
max_idontwant_messages
(ignore the IDONWANT packets if the max is reached)More requested features
Spec: libp2p/specs#548