Skip to content
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

Merged
merged 2 commits into from
Jul 28, 2023
Merged

GossipSub: IDontWant #934

merged 2 commits into from
Jul 28, 2023

Conversation

Menduist
Copy link
Contributor

Implements libp2p/specs#548

@codecov
Copy link

codecov bot commented Jul 24, 2023

Codecov Report

Merging #934 (85bac25) into unstable (440461b) will increase coverage by 0.02%.
The diff coverage is 100.00%.

Additional details and impacted files

Impacted file tree graph

@@             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              
Files Changed Coverage Δ
libp2p/protocols/pubsub/rpc/messages.nim 15.38% <ø> (ø)
libp2p/protocols/pubsub/gossipsub.nim 86.75% <100.00%> (+0.38%) ⬆️
libp2p/protocols/pubsub/gossipsub/behavior.nim 88.14% <100.00%> (+0.30%) ⬆️
libp2p/protocols/pubsub/pubsubpeer.nim 90.90% <100.00%> (+0.06%) ⬆️
libp2p/protocols/pubsub/rpc/protobuf.nim 90.95% <100.00%> (+0.24%) ⬆️

@Menduist
Copy link
Contributor Author

Confirmed to work properly in sims (~15% BW reduction with: 500 nodes, 100mbps, 100ms ping, 0.5kb messages)
Stagger sending will reduce the bandwidth even further, since we will have more time to avoid a duplicate

@Menduist Menduist marked this pull request as ready for review July 25, 2023 14:34
@@ -332,11 +333,25 @@ proc validateAndRelay(g: GossipSub,
g.floodsub.withValue(t, peers): toSendPeers.incl(peers[])
g.mesh.withValue(t, peers): toSendPeers.incl(peers[])


Copy link
Contributor

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:
Copy link
Contributor

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]]
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

Choose a reason for hiding this comment

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

so maybe rcvDontWants.

Copy link
Contributor

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:
Copy link
Contributor

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
Copy link
Contributor

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?

@Menduist Menduist merged commit b784167 into unstable Jul 28, 2023
10 checks passed
@Menduist Menduist deleted the idontwant branch July 28, 2023 08:58
# 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(
Copy link
Contributor

@arnetheduck arnetheduck Aug 4, 2023

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

Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants