-
Notifications
You must be signed in to change notification settings - Fork 54
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: IDontWant #934
GossipSub: IDontWant #934
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## unstable #934 +/- ##
============================================
+ Coverage 83.43% 83.46% +0.02%
============================================
Files 91 91
Lines 15117 15144 +27
============================================
+ Hits 12613 12640 +27
Misses 2504 2504
|
Confirmed to work properly in sims (~15% BW reduction with: 500 nodes, 100mbps, 100ms ping, 0.5kb messages) |
@@ -332,11 +333,25 @@ proc validateAndRelay(g: GossipSub, | |||
g.floodsub.withValue(t, peers): toSendPeers.incl(peers[]) | |||
g.mesh.withValue(t, peers): toSendPeers.incl(peers[]) | |||
|
|||
|
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.
not necessary?
# Don't send it to source peer, or peers that | ||
# sent it during validation | ||
toSendPeers.excl(peer) | ||
toSendPeers.excl(seenPeers) | ||
|
||
if msg.data.len > msgId.len * 10: |
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.
Can we make this condition more descriptive - like making it a proc or adding a comment with the reasoning?
@@ -60,6 +60,7 @@ type | |||
|
|||
score*: float64 | |||
sentIHaves*: Deque[HashSet[MessageId]] | |||
heDontWants*: Deque[HashSet[MessageId]] |
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.
why not iDontWants
or sentIDontWants
?
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 the list of "iDontWant" he sent, so I think "heDontWants" or "receivedDontWants" is more descriptive
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 maybe rcvDontWants
.
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.
just dontWants
is enough really
peer: PubSubPeer, | ||
iDontWants: seq[ControlIWant]) = | ||
for dontWant in iDontWants: | ||
for message in dontWant.messageIds: |
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.
messageId
?
for dontWant in iDontWants: | ||
for message in dontWant.messageIds: | ||
if peer.heDontWants[^1].len > 1000: break | ||
if message.len > 100: break |
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.
should it be a continue
?
# IDontWant is only worth it if the message is substantially | ||
# bigger than the messageId | ||
if msg.data.len > msgId.len * 10: | ||
g.broadcast(toSendPeers, RPCMsg(control: some(ControlMessage( |
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.
we should only broadcast this to peers that haven't themselves sent us an idontwant for the given hash, ie this should be moved below
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.
That is true in this version of IDontWant, because as soon as we sent the IDontWant, we also send the full message, so it's too late to "choke" us
However, in future versions we might send the IDontWant earlier (before validation), or send the full message later (staggered sending)
So in these future versions, receiving a IDontWant won't mean it's too late to send ours. Sending the IDontWant to everyone is "forward-compatibility" at the cost of a few bytes
Implements libp2p/specs#548