-
Notifications
You must be signed in to change notification settings - Fork 55
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: Limit flood publishing #911
Changes from 4 commits
f2209dc
f50cdd4
07f7670
8f78a34
50aaaf4
30e0dae
652e781
c10c232
d974bc4
b06e362
136296f
f68b32a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -488,20 +488,28 @@ method publish*(g: GossipSub, | |
|
||
var peers: HashSet[PubSubPeer] | ||
|
||
# add always direct peers | ||
peers.incl(g.explicit.getOrDefault(topic)) | ||
|
||
if topic in g.topics: # if we're subscribed use the mesh | ||
peers.incl(g.mesh.getOrDefault(topic)) | ||
|
||
if g.parameters.floodPublish: | ||
let | ||
msgSize = data.len | ||
bandwidth = 25_000_000 #TODO replace with bandwidth estimate | ||
msToTransmit = max(msgSize div (bandwidth div 1000), 1) | ||
maxFloodPublish = | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. no need for a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If the messages are that big (2mb), it will effectively disable flood publish There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. consider the case where we're not subscribed to the topic - sending to 0 peers seems a bit harsh then... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right, that won't happen before >50mb, but still good to cover it There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. thought a bit more about this, and I think we want to put the minimum at dmin at least .. it feels very risky to send only to one peer - if that peer is slow, it'll delay the message for all peers by a heartbeat and it relies a bit too heavily on the IHAVE/IWANT mechanism to recover, ie there's no redundancy... I know there's a cost here for sending big messages from slow peers, but I think the risk for normal/highbandwidth peers is more real and costly. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The minimum is currently dLow (it will be caught by the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. aren't fanout peers populated only when we're not subscribed? also as such, there might not be enough of them in the fanout table either? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We also use them when we can't publish to enough peers (ie bad mesh), and they are replenished when < dLow There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
so sending to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This should be the same as using the fanout, the fanout is only a small cache of |
||
(g.parameters.heartbeatInterval.milliseconds div msToTransmit) | ||
# With flood publishing enabled, the mesh is used when propagating messages from other peers, | ||
# but a peer's own messages will always be published to all known peers in the topic. | ||
# but a peer's own messages will always be published to all known peers in the topic, limited | ||
# to the amount of peers we can send it to in one heartbeat | ||
for peer in g.gossipsub.getOrDefault(topic): | ||
if peers.len >= maxFloodPublish: break | ||
if peer.score >= g.parameters.publishThreshold: | ||
trace "publish: including flood/high score peer", peer | ||
peers.incl(peer) | ||
|
||
# add always direct peers | ||
peers.incl(g.explicit.getOrDefault(topic)) | ||
|
||
if topic in g.topics: # if we're subscribed use the mesh | ||
peers.incl(g.mesh.getOrDefault(topic)) | ||
|
||
if peers.len < g.parameters.dLow and g.parameters.floodPublish == false: | ||
# not subscribed or bad mesh, send to fanout peers | ||
# disable for floodPublish, since we already sent to every good peer | ||
|
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 suspect we need to make this a (debug) parameter until we have something better - ie in nimbus-eth2, this would be a hidden command-line parameter that we pull out in case of weird behavior - hidden, because obviously it's something that should go away at some point