2020-01-25 02:16:02 +11:00
|
|
|
// Copyright 2020 Sigma Prime Pty Ltd.
|
|
|
|
//
|
|
|
|
// Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
// copy of this software and associated documentation files (the "Software"),
|
|
|
|
// to deal in the Software without restriction, including without limitation
|
|
|
|
// the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
// and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
// Software is furnished to do so, subject to the following conditions:
|
|
|
|
//
|
|
|
|
// The above copyright notice and this permission notice shall be included in
|
|
|
|
// all copies or substantial portions of the Software.
|
|
|
|
//
|
|
|
|
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
|
|
|
|
// OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
|
|
// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
// FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
|
|
|
|
// DEALINGS IN THE SOFTWARE.
|
|
|
|
|
|
|
|
use crate::topic::TopicHash;
|
2021-01-07 18:19:31 +11:00
|
|
|
use crate::types::{MessageId, RawGossipsubMessage};
|
|
|
|
use libp2p_core::PeerId;
|
protocols/gossipsub: Improve bandwidth (#2327)
This PR adds some bandwidth improvements to gossipsub.
After a bit of inspection on live networks a number of improvements have been
made that can help reduce unnecessary bandwidth on gossipsub networks. This PR
introduces the following:
- A 1:1 tracking of all in-flight IWANT requests. This not only ensures that all
IWANT requests are answered and peers penalized accordingly, but gossipsub
will no no longer create multiple IWANT requests for multiple peers.
Previously, gossipsub sampled the in-flight IWANT requests in order to
penalize peers for not responding with a high probability that we would detect
non-responsive nodes. Futher, it was possible to re-request IWANT messages
that are already being requested causing added duplication in messages and
wasted unnecessary IWANT control messages. This PR shifts this logic to only
request message ids that we are not currently requesting from peers.
- Triangle routing naturally gives rise to unnecessary duplicates. Consider a
mesh of 4 peers that are interconnected. Peer 1 sends a new message to 2,3,4.
2 propagates to 3,4 and 3 propagates to 2,4 and 4 propagates to 2,3. In this
case 3 has received the message 3 times. If we keep track of peers that send
us messages, when publishing or forwarding we no longer send to peers that
have sent us a duplicate, we can eliminate one of the sends in the scenario
above. This only occurs when message validation is async however. This PR adds
this logic to remove some elements of triangle-routing duplicates.
Co-authored-by: Divma <26765164+divagant-martian@users.noreply.github.com>
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Diva M <divma@protonmail.com>
2021-12-21 22:09:15 +11:00
|
|
|
use log::{debug, trace};
|
2021-01-07 18:19:31 +11:00
|
|
|
use std::fmt::Debug;
|
protocols/gossipsub: Improve bandwidth (#2327)
This PR adds some bandwidth improvements to gossipsub.
After a bit of inspection on live networks a number of improvements have been
made that can help reduce unnecessary bandwidth on gossipsub networks. This PR
introduces the following:
- A 1:1 tracking of all in-flight IWANT requests. This not only ensures that all
IWANT requests are answered and peers penalized accordingly, but gossipsub
will no no longer create multiple IWANT requests for multiple peers.
Previously, gossipsub sampled the in-flight IWANT requests in order to
penalize peers for not responding with a high probability that we would detect
non-responsive nodes. Futher, it was possible to re-request IWANT messages
that are already being requested causing added duplication in messages and
wasted unnecessary IWANT control messages. This PR shifts this logic to only
request message ids that we are not currently requesting from peers.
- Triangle routing naturally gives rise to unnecessary duplicates. Consider a
mesh of 4 peers that are interconnected. Peer 1 sends a new message to 2,3,4.
2 propagates to 3,4 and 3 propagates to 2,4 and 4 propagates to 2,3. In this
case 3 has received the message 3 times. If we keep track of peers that send
us messages, when publishing or forwarding we no longer send to peers that
have sent us a duplicate, we can eliminate one of the sends in the scenario
above. This only occurs when message validation is async however. This PR adds
this logic to remove some elements of triangle-routing duplicates.
Co-authored-by: Divma <26765164+divagant-martian@users.noreply.github.com>
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Diva M <divma@protonmail.com>
2021-12-21 22:09:15 +11:00
|
|
|
use std::{
|
|
|
|
collections::{HashMap, HashSet},
|
|
|
|
fmt,
|
|
|
|
};
|
2020-01-25 02:16:02 +11:00
|
|
|
|
|
|
|
/// CacheEntry stored in the history.
|
|
|
|
#[derive(Debug, Clone, PartialEq, Eq, Hash)]
|
|
|
|
pub struct CacheEntry {
|
|
|
|
mid: MessageId,
|
2021-01-07 18:19:31 +11:00
|
|
|
topic: TopicHash,
|
2020-01-25 02:16:02 +11:00
|
|
|
}
|
|
|
|
|
|
|
|
/// MessageCache struct holding history of messages.
|
|
|
|
#[derive(Clone)]
|
|
|
|
pub struct MessageCache {
|
protocols/gossipsub: Improve bandwidth (#2327)
This PR adds some bandwidth improvements to gossipsub.
After a bit of inspection on live networks a number of improvements have been
made that can help reduce unnecessary bandwidth on gossipsub networks. This PR
introduces the following:
- A 1:1 tracking of all in-flight IWANT requests. This not only ensures that all
IWANT requests are answered and peers penalized accordingly, but gossipsub
will no no longer create multiple IWANT requests for multiple peers.
Previously, gossipsub sampled the in-flight IWANT requests in order to
penalize peers for not responding with a high probability that we would detect
non-responsive nodes. Futher, it was possible to re-request IWANT messages
that are already being requested causing added duplication in messages and
wasted unnecessary IWANT control messages. This PR shifts this logic to only
request message ids that we are not currently requesting from peers.
- Triangle routing naturally gives rise to unnecessary duplicates. Consider a
mesh of 4 peers that are interconnected. Peer 1 sends a new message to 2,3,4.
2 propagates to 3,4 and 3 propagates to 2,4 and 4 propagates to 2,3. In this
case 3 has received the message 3 times. If we keep track of peers that send
us messages, when publishing or forwarding we no longer send to peers that
have sent us a duplicate, we can eliminate one of the sends in the scenario
above. This only occurs when message validation is async however. This PR adds
this logic to remove some elements of triangle-routing duplicates.
Co-authored-by: Divma <26765164+divagant-martian@users.noreply.github.com>
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Diva M <divma@protonmail.com>
2021-12-21 22:09:15 +11:00
|
|
|
msgs: HashMap<MessageId, (RawGossipsubMessage, HashSet<PeerId>)>,
|
2021-01-07 18:19:31 +11:00
|
|
|
/// For every message and peer the number of times this peer asked for the message
|
|
|
|
iwant_counts: HashMap<MessageId, HashMap<PeerId, u32>>,
|
2020-01-25 02:16:02 +11:00
|
|
|
history: Vec<Vec<CacheEntry>>,
|
protocols/gossipsub: Improve bandwidth (#2327)
This PR adds some bandwidth improvements to gossipsub.
After a bit of inspection on live networks a number of improvements have been
made that can help reduce unnecessary bandwidth on gossipsub networks. This PR
introduces the following:
- A 1:1 tracking of all in-flight IWANT requests. This not only ensures that all
IWANT requests are answered and peers penalized accordingly, but gossipsub
will no no longer create multiple IWANT requests for multiple peers.
Previously, gossipsub sampled the in-flight IWANT requests in order to
penalize peers for not responding with a high probability that we would detect
non-responsive nodes. Futher, it was possible to re-request IWANT messages
that are already being requested causing added duplication in messages and
wasted unnecessary IWANT control messages. This PR shifts this logic to only
request message ids that we are not currently requesting from peers.
- Triangle routing naturally gives rise to unnecessary duplicates. Consider a
mesh of 4 peers that are interconnected. Peer 1 sends a new message to 2,3,4.
2 propagates to 3,4 and 3 propagates to 2,4 and 4 propagates to 2,3. In this
case 3 has received the message 3 times. If we keep track of peers that send
us messages, when publishing or forwarding we no longer send to peers that
have sent us a duplicate, we can eliminate one of the sends in the scenario
above. This only occurs when message validation is async however. This PR adds
this logic to remove some elements of triangle-routing duplicates.
Co-authored-by: Divma <26765164+divagant-martian@users.noreply.github.com>
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Diva M <divma@protonmail.com>
2021-12-21 22:09:15 +11:00
|
|
|
/// The number of indices in the cache history used for gossiping. That means that a message
|
|
|
|
/// won't get gossiped anymore when shift got called `gossip` many times after inserting the
|
2021-01-07 18:19:31 +11:00
|
|
|
/// message in the cache.
|
2020-01-25 02:16:02 +11:00
|
|
|
gossip: usize,
|
|
|
|
}
|
|
|
|
|
2020-07-29 09:25:53 +02:00
|
|
|
impl fmt::Debug for MessageCache {
|
|
|
|
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
|
|
|
|
f.debug_struct("MessageCache")
|
|
|
|
.field("msgs", &self.msgs)
|
|
|
|
.field("history", &self.history)
|
|
|
|
.field("gossip", &self.gossip)
|
|
|
|
.finish()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-01-25 02:16:02 +11:00
|
|
|
/// Implementation of the MessageCache.
|
|
|
|
impl MessageCache {
|
2021-01-07 18:19:31 +11:00
|
|
|
pub fn new(gossip: usize, history_capacity: usize) -> Self {
|
2020-01-25 02:16:02 +11:00
|
|
|
MessageCache {
|
|
|
|
gossip,
|
|
|
|
msgs: HashMap::default(),
|
2021-01-07 18:19:31 +11:00
|
|
|
iwant_counts: HashMap::default(),
|
2020-01-25 02:16:02 +11:00
|
|
|
history: vec![Vec::new(); history_capacity],
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-08-03 18:13:43 +10:00
|
|
|
/// Put a message into the memory cache.
|
|
|
|
///
|
protocols/gossipsub: Improve bandwidth (#2327)
This PR adds some bandwidth improvements to gossipsub.
After a bit of inspection on live networks a number of improvements have been
made that can help reduce unnecessary bandwidth on gossipsub networks. This PR
introduces the following:
- A 1:1 tracking of all in-flight IWANT requests. This not only ensures that all
IWANT requests are answered and peers penalized accordingly, but gossipsub
will no no longer create multiple IWANT requests for multiple peers.
Previously, gossipsub sampled the in-flight IWANT requests in order to
penalize peers for not responding with a high probability that we would detect
non-responsive nodes. Futher, it was possible to re-request IWANT messages
that are already being requested causing added duplication in messages and
wasted unnecessary IWANT control messages. This PR shifts this logic to only
request message ids that we are not currently requesting from peers.
- Triangle routing naturally gives rise to unnecessary duplicates. Consider a
mesh of 4 peers that are interconnected. Peer 1 sends a new message to 2,3,4.
2 propagates to 3,4 and 3 propagates to 2,4 and 4 propagates to 2,3. In this
case 3 has received the message 3 times. If we keep track of peers that send
us messages, when publishing or forwarding we no longer send to peers that
have sent us a duplicate, we can eliminate one of the sends in the scenario
above. This only occurs when message validation is async however. This PR adds
this logic to remove some elements of triangle-routing duplicates.
Co-authored-by: Divma <26765164+divagant-martian@users.noreply.github.com>
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Diva M <divma@protonmail.com>
2021-12-21 22:09:15 +11:00
|
|
|
/// Returns true if the message didn't already exist in the cache.
|
|
|
|
pub fn put(&mut self, message_id: &MessageId, msg: RawGossipsubMessage) -> bool {
|
|
|
|
trace!("Put message {:?} in mcache", message_id);
|
2020-01-25 02:16:02 +11:00
|
|
|
let cache_entry = CacheEntry {
|
|
|
|
mid: message_id.clone(),
|
2021-01-07 18:19:31 +11:00
|
|
|
topic: msg.topic.clone(),
|
2020-01-25 02:16:02 +11:00
|
|
|
};
|
|
|
|
|
protocols/gossipsub: Improve bandwidth (#2327)
This PR adds some bandwidth improvements to gossipsub.
After a bit of inspection on live networks a number of improvements have been
made that can help reduce unnecessary bandwidth on gossipsub networks. This PR
introduces the following:
- A 1:1 tracking of all in-flight IWANT requests. This not only ensures that all
IWANT requests are answered and peers penalized accordingly, but gossipsub
will no no longer create multiple IWANT requests for multiple peers.
Previously, gossipsub sampled the in-flight IWANT requests in order to
penalize peers for not responding with a high probability that we would detect
non-responsive nodes. Futher, it was possible to re-request IWANT messages
that are already being requested causing added duplication in messages and
wasted unnecessary IWANT control messages. This PR shifts this logic to only
request message ids that we are not currently requesting from peers.
- Triangle routing naturally gives rise to unnecessary duplicates. Consider a
mesh of 4 peers that are interconnected. Peer 1 sends a new message to 2,3,4.
2 propagates to 3,4 and 3 propagates to 2,4 and 4 propagates to 2,3. In this
case 3 has received the message 3 times. If we keep track of peers that send
us messages, when publishing or forwarding we no longer send to peers that
have sent us a duplicate, we can eliminate one of the sends in the scenario
above. This only occurs when message validation is async however. This PR adds
this logic to remove some elements of triangle-routing duplicates.
Co-authored-by: Divma <26765164+divagant-martian@users.noreply.github.com>
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Diva M <divma@protonmail.com>
2021-12-21 22:09:15 +11:00
|
|
|
if self
|
|
|
|
.msgs
|
|
|
|
.insert(message_id.clone(), (msg, HashSet::new()))
|
|
|
|
.is_none()
|
|
|
|
{
|
2020-08-03 18:13:43 +10:00
|
|
|
// Don't add duplicate entries to the cache.
|
|
|
|
self.history[0].push(cache_entry);
|
protocols/gossipsub: Improve bandwidth (#2327)
This PR adds some bandwidth improvements to gossipsub.
After a bit of inspection on live networks a number of improvements have been
made that can help reduce unnecessary bandwidth on gossipsub networks. This PR
introduces the following:
- A 1:1 tracking of all in-flight IWANT requests. This not only ensures that all
IWANT requests are answered and peers penalized accordingly, but gossipsub
will no no longer create multiple IWANT requests for multiple peers.
Previously, gossipsub sampled the in-flight IWANT requests in order to
penalize peers for not responding with a high probability that we would detect
non-responsive nodes. Futher, it was possible to re-request IWANT messages
that are already being requested causing added duplication in messages and
wasted unnecessary IWANT control messages. This PR shifts this logic to only
request message ids that we are not currently requesting from peers.
- Triangle routing naturally gives rise to unnecessary duplicates. Consider a
mesh of 4 peers that are interconnected. Peer 1 sends a new message to 2,3,4.
2 propagates to 3,4 and 3 propagates to 2,4 and 4 propagates to 2,3. In this
case 3 has received the message 3 times. If we keep track of peers that send
us messages, when publishing or forwarding we no longer send to peers that
have sent us a duplicate, we can eliminate one of the sends in the scenario
above. This only occurs when message validation is async however. This PR adds
this logic to remove some elements of triangle-routing duplicates.
Co-authored-by: Divma <26765164+divagant-martian@users.noreply.github.com>
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Diva M <divma@protonmail.com>
2021-12-21 22:09:15 +11:00
|
|
|
return true;
|
|
|
|
} else {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Keeps track of peers we know have received the message to prevent forwarding to said peers.
|
|
|
|
pub fn observe_duplicate(&mut self, message_id: &MessageId, source: &PeerId) {
|
|
|
|
if let Some((message, originating_peers)) = self.msgs.get_mut(message_id) {
|
|
|
|
// if the message is already validated, we don't need to store extra peers sending us
|
|
|
|
// duplicates as the message has already been forwarded
|
|
|
|
if message.validated {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
originating_peers.insert(*source);
|
2020-08-03 18:13:43 +10:00
|
|
|
}
|
2020-01-25 02:16:02 +11:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Get a message with `message_id`
|
2021-01-07 18:19:31 +11:00
|
|
|
#[cfg(test)]
|
|
|
|
pub fn get(&self, message_id: &MessageId) -> Option<&RawGossipsubMessage> {
|
protocols/gossipsub: Improve bandwidth (#2327)
This PR adds some bandwidth improvements to gossipsub.
After a bit of inspection on live networks a number of improvements have been
made that can help reduce unnecessary bandwidth on gossipsub networks. This PR
introduces the following:
- A 1:1 tracking of all in-flight IWANT requests. This not only ensures that all
IWANT requests are answered and peers penalized accordingly, but gossipsub
will no no longer create multiple IWANT requests for multiple peers.
Previously, gossipsub sampled the in-flight IWANT requests in order to
penalize peers for not responding with a high probability that we would detect
non-responsive nodes. Futher, it was possible to re-request IWANT messages
that are already being requested causing added duplication in messages and
wasted unnecessary IWANT control messages. This PR shifts this logic to only
request message ids that we are not currently requesting from peers.
- Triangle routing naturally gives rise to unnecessary duplicates. Consider a
mesh of 4 peers that are interconnected. Peer 1 sends a new message to 2,3,4.
2 propagates to 3,4 and 3 propagates to 2,4 and 4 propagates to 2,3. In this
case 3 has received the message 3 times. If we keep track of peers that send
us messages, when publishing or forwarding we no longer send to peers that
have sent us a duplicate, we can eliminate one of the sends in the scenario
above. This only occurs when message validation is async however. This PR adds
this logic to remove some elements of triangle-routing duplicates.
Co-authored-by: Divma <26765164+divagant-martian@users.noreply.github.com>
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Diva M <divma@protonmail.com>
2021-12-21 22:09:15 +11:00
|
|
|
self.msgs.get(message_id).map(|(message, _)| message)
|
2020-01-25 02:16:02 +11:00
|
|
|
}
|
|
|
|
|
2021-01-07 18:19:31 +11:00
|
|
|
/// Increases the iwant count for the given message by one and returns the message together
|
|
|
|
/// with the iwant if the message exists.
|
|
|
|
pub fn get_with_iwant_counts(
|
|
|
|
&mut self,
|
|
|
|
message_id: &MessageId,
|
|
|
|
peer: &PeerId,
|
|
|
|
) -> Option<(&RawGossipsubMessage, u32)> {
|
|
|
|
let iwant_counts = &mut self.iwant_counts;
|
protocols/gossipsub: Improve bandwidth (#2327)
This PR adds some bandwidth improvements to gossipsub.
After a bit of inspection on live networks a number of improvements have been
made that can help reduce unnecessary bandwidth on gossipsub networks. This PR
introduces the following:
- A 1:1 tracking of all in-flight IWANT requests. This not only ensures that all
IWANT requests are answered and peers penalized accordingly, but gossipsub
will no no longer create multiple IWANT requests for multiple peers.
Previously, gossipsub sampled the in-flight IWANT requests in order to
penalize peers for not responding with a high probability that we would detect
non-responsive nodes. Futher, it was possible to re-request IWANT messages
that are already being requested causing added duplication in messages and
wasted unnecessary IWANT control messages. This PR shifts this logic to only
request message ids that we are not currently requesting from peers.
- Triangle routing naturally gives rise to unnecessary duplicates. Consider a
mesh of 4 peers that are interconnected. Peer 1 sends a new message to 2,3,4.
2 propagates to 3,4 and 3 propagates to 2,4 and 4 propagates to 2,3. In this
case 3 has received the message 3 times. If we keep track of peers that send
us messages, when publishing or forwarding we no longer send to peers that
have sent us a duplicate, we can eliminate one of the sends in the scenario
above. This only occurs when message validation is async however. This PR adds
this logic to remove some elements of triangle-routing duplicates.
Co-authored-by: Divma <26765164+divagant-martian@users.noreply.github.com>
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Diva M <divma@protonmail.com>
2021-12-21 22:09:15 +11:00
|
|
|
self.msgs.get(message_id).and_then(|(message, _)| {
|
2021-01-07 18:19:31 +11:00
|
|
|
if !message.validated {
|
|
|
|
None
|
|
|
|
} else {
|
|
|
|
Some((message, {
|
|
|
|
let count = iwant_counts
|
|
|
|
.entry(message_id.clone())
|
|
|
|
.or_default()
|
2021-02-15 11:59:51 +01:00
|
|
|
.entry(*peer)
|
2021-01-07 18:19:31 +11:00
|
|
|
.or_default();
|
|
|
|
*count += 1;
|
|
|
|
*count
|
|
|
|
}))
|
|
|
|
}
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Gets a message with [`MessageId`] and tags it as validated.
|
protocols/gossipsub: Improve bandwidth (#2327)
This PR adds some bandwidth improvements to gossipsub.
After a bit of inspection on live networks a number of improvements have been
made that can help reduce unnecessary bandwidth on gossipsub networks. This PR
introduces the following:
- A 1:1 tracking of all in-flight IWANT requests. This not only ensures that all
IWANT requests are answered and peers penalized accordingly, but gossipsub
will no no longer create multiple IWANT requests for multiple peers.
Previously, gossipsub sampled the in-flight IWANT requests in order to
penalize peers for not responding with a high probability that we would detect
non-responsive nodes. Futher, it was possible to re-request IWANT messages
that are already being requested causing added duplication in messages and
wasted unnecessary IWANT control messages. This PR shifts this logic to only
request message ids that we are not currently requesting from peers.
- Triangle routing naturally gives rise to unnecessary duplicates. Consider a
mesh of 4 peers that are interconnected. Peer 1 sends a new message to 2,3,4.
2 propagates to 3,4 and 3 propagates to 2,4 and 4 propagates to 2,3. In this
case 3 has received the message 3 times. If we keep track of peers that send
us messages, when publishing or forwarding we no longer send to peers that
have sent us a duplicate, we can eliminate one of the sends in the scenario
above. This only occurs when message validation is async however. This PR adds
this logic to remove some elements of triangle-routing duplicates.
Co-authored-by: Divma <26765164+divagant-martian@users.noreply.github.com>
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Diva M <divma@protonmail.com>
2021-12-21 22:09:15 +11:00
|
|
|
/// This function also returns the known peers that have sent us this message. This is used to
|
|
|
|
/// prevent us sending redundant messages to peers who have already propagated it.
|
|
|
|
pub fn validate(
|
|
|
|
&mut self,
|
|
|
|
message_id: &MessageId,
|
|
|
|
) -> Option<(&RawGossipsubMessage, HashSet<PeerId>)> {
|
|
|
|
self.msgs.get_mut(message_id).map(|(message, known_peers)| {
|
2020-08-03 18:13:43 +10:00
|
|
|
message.validated = true;
|
protocols/gossipsub: Improve bandwidth (#2327)
This PR adds some bandwidth improvements to gossipsub.
After a bit of inspection on live networks a number of improvements have been
made that can help reduce unnecessary bandwidth on gossipsub networks. This PR
introduces the following:
- A 1:1 tracking of all in-flight IWANT requests. This not only ensures that all
IWANT requests are answered and peers penalized accordingly, but gossipsub
will no no longer create multiple IWANT requests for multiple peers.
Previously, gossipsub sampled the in-flight IWANT requests in order to
penalize peers for not responding with a high probability that we would detect
non-responsive nodes. Futher, it was possible to re-request IWANT messages
that are already being requested causing added duplication in messages and
wasted unnecessary IWANT control messages. This PR shifts this logic to only
request message ids that we are not currently requesting from peers.
- Triangle routing naturally gives rise to unnecessary duplicates. Consider a
mesh of 4 peers that are interconnected. Peer 1 sends a new message to 2,3,4.
2 propagates to 3,4 and 3 propagates to 2,4 and 4 propagates to 2,3. In this
case 3 has received the message 3 times. If we keep track of peers that send
us messages, when publishing or forwarding we no longer send to peers that
have sent us a duplicate, we can eliminate one of the sends in the scenario
above. This only occurs when message validation is async however. This PR adds
this logic to remove some elements of triangle-routing duplicates.
Co-authored-by: Divma <26765164+divagant-martian@users.noreply.github.com>
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Diva M <divma@protonmail.com>
2021-12-21 22:09:15 +11:00
|
|
|
// Clear the known peers list (after a message is validated, it is forwarded and we no
|
|
|
|
// longer need to store the originating peers).
|
|
|
|
let originating_peers = std::mem::replace(known_peers, HashSet::new());
|
|
|
|
(&*message, originating_peers)
|
2020-08-03 18:13:43 +10:00
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2021-01-07 18:19:31 +11:00
|
|
|
/// Get a list of [`MessageId`]s for a given topic.
|
|
|
|
pub fn get_gossip_message_ids(&self, topic: &TopicHash) -> Vec<MessageId> {
|
2020-01-25 02:16:02 +11:00
|
|
|
self.history[..self.gossip]
|
|
|
|
.iter()
|
|
|
|
.fold(vec![], |mut current_entries, entries| {
|
|
|
|
// search for entries with desired topic
|
|
|
|
let mut found_entries: Vec<MessageId> = entries
|
|
|
|
.iter()
|
|
|
|
.filter_map(|entry| {
|
2021-01-07 18:19:31 +11:00
|
|
|
if &entry.topic == topic {
|
2020-08-03 18:13:43 +10:00
|
|
|
let mid = &entry.mid;
|
|
|
|
// Only gossip validated messages
|
protocols/gossipsub: Improve bandwidth (#2327)
This PR adds some bandwidth improvements to gossipsub.
After a bit of inspection on live networks a number of improvements have been
made that can help reduce unnecessary bandwidth on gossipsub networks. This PR
introduces the following:
- A 1:1 tracking of all in-flight IWANT requests. This not only ensures that all
IWANT requests are answered and peers penalized accordingly, but gossipsub
will no no longer create multiple IWANT requests for multiple peers.
Previously, gossipsub sampled the in-flight IWANT requests in order to
penalize peers for not responding with a high probability that we would detect
non-responsive nodes. Futher, it was possible to re-request IWANT messages
that are already being requested causing added duplication in messages and
wasted unnecessary IWANT control messages. This PR shifts this logic to only
request message ids that we are not currently requesting from peers.
- Triangle routing naturally gives rise to unnecessary duplicates. Consider a
mesh of 4 peers that are interconnected. Peer 1 sends a new message to 2,3,4.
2 propagates to 3,4 and 3 propagates to 2,4 and 4 propagates to 2,3. In this
case 3 has received the message 3 times. If we keep track of peers that send
us messages, when publishing or forwarding we no longer send to peers that
have sent us a duplicate, we can eliminate one of the sends in the scenario
above. This only occurs when message validation is async however. This PR adds
this logic to remove some elements of triangle-routing duplicates.
Co-authored-by: Divma <26765164+divagant-martian@users.noreply.github.com>
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Diva M <divma@protonmail.com>
2021-12-21 22:09:15 +11:00
|
|
|
if let Some(true) = self.msgs.get(mid).map(|(msg, _)| msg.validated) {
|
2020-08-03 18:13:43 +10:00
|
|
|
Some(mid.clone())
|
|
|
|
} else {
|
|
|
|
None
|
|
|
|
}
|
2020-01-25 02:16:02 +11:00
|
|
|
} else {
|
|
|
|
None
|
|
|
|
}
|
|
|
|
})
|
|
|
|
.collect();
|
|
|
|
|
|
|
|
// generate the list
|
|
|
|
current_entries.append(&mut found_entries);
|
|
|
|
current_entries
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Shift the history array down one and delete messages associated with the
|
2021-01-07 18:19:31 +11:00
|
|
|
/// last entry.
|
2020-01-25 02:16:02 +11:00
|
|
|
pub fn shift(&mut self) {
|
|
|
|
for entry in self.history.pop().expect("history is always > 1") {
|
protocols/gossipsub: Improve bandwidth (#2327)
This PR adds some bandwidth improvements to gossipsub.
After a bit of inspection on live networks a number of improvements have been
made that can help reduce unnecessary bandwidth on gossipsub networks. This PR
introduces the following:
- A 1:1 tracking of all in-flight IWANT requests. This not only ensures that all
IWANT requests are answered and peers penalized accordingly, but gossipsub
will no no longer create multiple IWANT requests for multiple peers.
Previously, gossipsub sampled the in-flight IWANT requests in order to
penalize peers for not responding with a high probability that we would detect
non-responsive nodes. Futher, it was possible to re-request IWANT messages
that are already being requested causing added duplication in messages and
wasted unnecessary IWANT control messages. This PR shifts this logic to only
request message ids that we are not currently requesting from peers.
- Triangle routing naturally gives rise to unnecessary duplicates. Consider a
mesh of 4 peers that are interconnected. Peer 1 sends a new message to 2,3,4.
2 propagates to 3,4 and 3 propagates to 2,4 and 4 propagates to 2,3. In this
case 3 has received the message 3 times. If we keep track of peers that send
us messages, when publishing or forwarding we no longer send to peers that
have sent us a duplicate, we can eliminate one of the sends in the scenario
above. This only occurs when message validation is async however. This PR adds
this logic to remove some elements of triangle-routing duplicates.
Co-authored-by: Divma <26765164+divagant-martian@users.noreply.github.com>
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Diva M <divma@protonmail.com>
2021-12-21 22:09:15 +11:00
|
|
|
if let Some((msg, _)) = self.msgs.remove(&entry.mid) {
|
2021-01-07 18:19:31 +11:00
|
|
|
if !msg.validated {
|
|
|
|
// If GossipsubConfig::validate_messages is true, the implementing
|
|
|
|
// application has to ensure that Gossipsub::validate_message gets called for
|
|
|
|
// each received message within the cache timeout time."
|
|
|
|
debug!(
|
|
|
|
"The message with id {} got removed from the cache without being validated.",
|
|
|
|
&entry.mid
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
protocols/gossipsub: Improve bandwidth (#2327)
This PR adds some bandwidth improvements to gossipsub.
After a bit of inspection on live networks a number of improvements have been
made that can help reduce unnecessary bandwidth on gossipsub networks. This PR
introduces the following:
- A 1:1 tracking of all in-flight IWANT requests. This not only ensures that all
IWANT requests are answered and peers penalized accordingly, but gossipsub
will no no longer create multiple IWANT requests for multiple peers.
Previously, gossipsub sampled the in-flight IWANT requests in order to
penalize peers for not responding with a high probability that we would detect
non-responsive nodes. Futher, it was possible to re-request IWANT messages
that are already being requested causing added duplication in messages and
wasted unnecessary IWANT control messages. This PR shifts this logic to only
request message ids that we are not currently requesting from peers.
- Triangle routing naturally gives rise to unnecessary duplicates. Consider a
mesh of 4 peers that are interconnected. Peer 1 sends a new message to 2,3,4.
2 propagates to 3,4 and 3 propagates to 2,4 and 4 propagates to 2,3. In this
case 3 has received the message 3 times. If we keep track of peers that send
us messages, when publishing or forwarding we no longer send to peers that
have sent us a duplicate, we can eliminate one of the sends in the scenario
above. This only occurs when message validation is async however. This PR adds
this logic to remove some elements of triangle-routing duplicates.
Co-authored-by: Divma <26765164+divagant-martian@users.noreply.github.com>
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Diva M <divma@protonmail.com>
2021-12-21 22:09:15 +11:00
|
|
|
trace!("Remove message from the cache: {}", &entry.mid);
|
2021-01-07 18:19:31 +11:00
|
|
|
|
|
|
|
self.iwant_counts.remove(&entry.mid);
|
2020-01-25 02:16:02 +11:00
|
|
|
}
|
|
|
|
|
|
|
|
// Insert an empty vec in position 0
|
|
|
|
self.history.insert(0, Vec::new());
|
|
|
|
}
|
2021-01-07 18:19:31 +11:00
|
|
|
|
|
|
|
/// Removes a message from the cache and returns it if existent
|
protocols/gossipsub: Improve bandwidth (#2327)
This PR adds some bandwidth improvements to gossipsub.
After a bit of inspection on live networks a number of improvements have been
made that can help reduce unnecessary bandwidth on gossipsub networks. This PR
introduces the following:
- A 1:1 tracking of all in-flight IWANT requests. This not only ensures that all
IWANT requests are answered and peers penalized accordingly, but gossipsub
will no no longer create multiple IWANT requests for multiple peers.
Previously, gossipsub sampled the in-flight IWANT requests in order to
penalize peers for not responding with a high probability that we would detect
non-responsive nodes. Futher, it was possible to re-request IWANT messages
that are already being requested causing added duplication in messages and
wasted unnecessary IWANT control messages. This PR shifts this logic to only
request message ids that we are not currently requesting from peers.
- Triangle routing naturally gives rise to unnecessary duplicates. Consider a
mesh of 4 peers that are interconnected. Peer 1 sends a new message to 2,3,4.
2 propagates to 3,4 and 3 propagates to 2,4 and 4 propagates to 2,3. In this
case 3 has received the message 3 times. If we keep track of peers that send
us messages, when publishing or forwarding we no longer send to peers that
have sent us a duplicate, we can eliminate one of the sends in the scenario
above. This only occurs when message validation is async however. This PR adds
this logic to remove some elements of triangle-routing duplicates.
Co-authored-by: Divma <26765164+divagant-martian@users.noreply.github.com>
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Diva M <divma@protonmail.com>
2021-12-21 22:09:15 +11:00
|
|
|
pub fn remove(
|
|
|
|
&mut self,
|
|
|
|
message_id: &MessageId,
|
|
|
|
) -> Option<(RawGossipsubMessage, HashSet<PeerId>)> {
|
2021-01-07 18:19:31 +11:00
|
|
|
//We only remove the message from msgs and iwant_count and keep the message_id in the
|
|
|
|
// history vector. Zhe id in the history vector will simply be ignored on popping.
|
|
|
|
|
|
|
|
self.iwant_counts.remove(message_id);
|
|
|
|
self.msgs.remove(message_id)
|
|
|
|
}
|
2020-01-25 02:16:02 +11:00
|
|
|
}
|
|
|
|
|
|
|
|
#[cfg(test)]
|
|
|
|
mod tests {
|
|
|
|
use super::*;
|
2021-01-07 18:19:31 +11:00
|
|
|
use crate::types::RawGossipsubMessage;
|
|
|
|
use crate::{IdentTopic as Topic, TopicHash};
|
2020-01-25 02:16:02 +11:00
|
|
|
use libp2p_core::PeerId;
|
|
|
|
|
2021-01-07 18:19:31 +11:00
|
|
|
fn gen_testm(x: u64, topic: TopicHash) -> (MessageId, RawGossipsubMessage) {
|
|
|
|
let default_id = |message: &RawGossipsubMessage| {
|
|
|
|
// default message id is: source + sequence number
|
|
|
|
let mut source_string = message.source.as_ref().unwrap().to_base58();
|
|
|
|
source_string.push_str(&message.sequence_number.unwrap().to_string());
|
|
|
|
MessageId::from(source_string)
|
|
|
|
};
|
2020-01-25 02:16:02 +11:00
|
|
|
let u8x: u8 = x as u8;
|
2020-08-03 18:13:43 +10:00
|
|
|
let source = Some(PeerId::random());
|
2020-01-25 02:16:02 +11:00
|
|
|
let data: Vec<u8> = vec![u8x];
|
2020-08-03 18:13:43 +10:00
|
|
|
let sequence_number = Some(x);
|
2020-01-25 02:16:02 +11:00
|
|
|
|
2021-01-07 18:19:31 +11:00
|
|
|
let m = RawGossipsubMessage {
|
2020-01-25 02:16:02 +11:00
|
|
|
source,
|
|
|
|
data,
|
|
|
|
sequence_number,
|
2021-01-07 18:19:31 +11:00
|
|
|
topic,
|
2020-08-03 18:13:43 +10:00
|
|
|
signature: None,
|
|
|
|
key: None,
|
2021-01-07 18:19:31 +11:00
|
|
|
validated: false,
|
2020-01-25 02:16:02 +11:00
|
|
|
};
|
2021-01-07 18:19:31 +11:00
|
|
|
|
|
|
|
let id = default_id(&m);
|
|
|
|
(id, m)
|
2020-01-25 02:16:02 +11:00
|
|
|
}
|
|
|
|
|
2020-08-03 18:13:43 +10:00
|
|
|
fn new_cache(gossip_size: usize, history: usize) -> MessageCache {
|
2021-01-07 18:19:31 +11:00
|
|
|
MessageCache::new(gossip_size, history)
|
2020-08-03 18:13:43 +10:00
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
/// Test that the message cache can be created.
|
|
|
|
fn test_new_cache() {
|
2020-01-25 02:16:02 +11:00
|
|
|
let x: usize = 3;
|
2020-08-03 18:13:43 +10:00
|
|
|
let mc = new_cache(x, 5);
|
2020-01-25 02:16:02 +11:00
|
|
|
|
|
|
|
assert_eq!(mc.gossip, x);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
/// Test you can put one message and get one.
|
|
|
|
fn test_put_get_one() {
|
2020-08-03 18:13:43 +10:00
|
|
|
let mut mc = new_cache(10, 15);
|
2020-01-25 02:16:02 +11:00
|
|
|
|
2021-01-07 18:19:31 +11:00
|
|
|
let topic1_hash = Topic::new("topic1").hash().clone();
|
|
|
|
let (id, m) = gen_testm(10, topic1_hash);
|
2020-01-25 02:16:02 +11:00
|
|
|
|
2021-01-07 18:19:31 +11:00
|
|
|
mc.put(&id, m.clone());
|
2020-01-25 02:16:02 +11:00
|
|
|
|
|
|
|
assert!(mc.history[0].len() == 1);
|
|
|
|
|
2021-01-07 18:19:31 +11:00
|
|
|
let fetched = mc.get(&id);
|
2020-01-25 02:16:02 +11:00
|
|
|
|
|
|
|
assert_eq!(fetched.is_none(), false);
|
|
|
|
assert_eq!(fetched.is_some(), true);
|
|
|
|
|
|
|
|
// Make sure it is the same fetched message
|
|
|
|
match fetched {
|
|
|
|
Some(x) => assert_eq!(*x, m),
|
|
|
|
_ => assert!(false),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
/// Test attempting to 'get' with a wrong id.
|
|
|
|
fn test_get_wrong() {
|
2020-08-03 18:13:43 +10:00
|
|
|
let mut mc = new_cache(10, 15);
|
2020-01-25 02:16:02 +11:00
|
|
|
|
2021-01-07 18:19:31 +11:00
|
|
|
let topic1_hash = Topic::new("topic1").hash().clone();
|
|
|
|
let (id, m) = gen_testm(10, topic1_hash);
|
2020-01-25 02:16:02 +11:00
|
|
|
|
2021-01-07 18:19:31 +11:00
|
|
|
mc.put(&id, m.clone());
|
2020-01-25 02:16:02 +11:00
|
|
|
|
|
|
|
// Try to get an incorrect ID
|
2020-08-03 18:13:43 +10:00
|
|
|
let wrong_id = MessageId::new(b"wrongid");
|
2020-01-25 02:16:02 +11:00
|
|
|
let fetched = mc.get(&wrong_id);
|
|
|
|
assert_eq!(fetched.is_none(), true);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
/// Test attempting to 'get' empty message cache.
|
|
|
|
fn test_get_empty() {
|
2020-08-03 18:13:43 +10:00
|
|
|
let mc = new_cache(10, 15);
|
2020-01-25 02:16:02 +11:00
|
|
|
|
|
|
|
// Try to get an incorrect ID
|
2020-08-03 18:13:43 +10:00
|
|
|
let wrong_string = MessageId::new(b"imempty");
|
2020-01-25 02:16:02 +11:00
|
|
|
let fetched = mc.get(&wrong_string);
|
|
|
|
assert_eq!(fetched.is_none(), true);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
/// Test shift mechanism.
|
|
|
|
fn test_shift() {
|
2020-08-03 18:13:43 +10:00
|
|
|
let mut mc = new_cache(1, 5);
|
2020-01-25 02:16:02 +11:00
|
|
|
|
2021-01-07 18:19:31 +11:00
|
|
|
let topic1_hash = Topic::new("topic1").hash().clone();
|
2020-01-25 02:16:02 +11:00
|
|
|
|
|
|
|
// Build the message
|
|
|
|
for i in 0..10 {
|
2021-01-07 18:19:31 +11:00
|
|
|
let (id, m) = gen_testm(i, topic1_hash.clone());
|
|
|
|
mc.put(&id, m.clone());
|
2020-01-25 02:16:02 +11:00
|
|
|
}
|
|
|
|
|
|
|
|
mc.shift();
|
|
|
|
|
|
|
|
// Ensure the shift occurred
|
|
|
|
assert!(mc.history[0].len() == 0);
|
|
|
|
assert!(mc.history[1].len() == 10);
|
|
|
|
|
|
|
|
// Make sure no messages deleted
|
|
|
|
assert!(mc.msgs.len() == 10);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
/// Test Shift with no additions.
|
|
|
|
fn test_empty_shift() {
|
2020-08-03 18:13:43 +10:00
|
|
|
let mut mc = new_cache(1, 5);
|
2020-01-25 02:16:02 +11:00
|
|
|
|
2021-01-07 18:19:31 +11:00
|
|
|
let topic1_hash = Topic::new("topic1").hash().clone();
|
|
|
|
|
2020-01-25 02:16:02 +11:00
|
|
|
// Build the message
|
|
|
|
for i in 0..10 {
|
2021-01-07 18:19:31 +11:00
|
|
|
let (id, m) = gen_testm(i, topic1_hash.clone());
|
|
|
|
mc.put(&id, m.clone());
|
2020-01-25 02:16:02 +11:00
|
|
|
}
|
|
|
|
|
|
|
|
mc.shift();
|
|
|
|
|
|
|
|
// Ensure the shift occurred
|
|
|
|
assert!(mc.history[0].len() == 0);
|
|
|
|
assert!(mc.history[1].len() == 10);
|
|
|
|
|
|
|
|
mc.shift();
|
|
|
|
|
|
|
|
assert!(mc.history[2].len() == 10);
|
|
|
|
assert!(mc.history[1].len() == 0);
|
|
|
|
assert!(mc.history[0].len() == 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
/// Test shift to see if the last history messages are removed.
|
|
|
|
fn test_remove_last_from_shift() {
|
2020-08-03 18:13:43 +10:00
|
|
|
let mut mc = new_cache(4, 5);
|
2020-01-25 02:16:02 +11:00
|
|
|
|
2021-01-07 18:19:31 +11:00
|
|
|
let topic1_hash = Topic::new("topic1").hash().clone();
|
|
|
|
|
2020-01-25 02:16:02 +11:00
|
|
|
// Build the message
|
|
|
|
for i in 0..10 {
|
2021-01-07 18:19:31 +11:00
|
|
|
let (id, m) = gen_testm(i, topic1_hash.clone());
|
|
|
|
mc.put(&id, m.clone());
|
2020-01-25 02:16:02 +11:00
|
|
|
}
|
|
|
|
|
|
|
|
// Shift right until deleting messages
|
|
|
|
mc.shift();
|
|
|
|
mc.shift();
|
|
|
|
mc.shift();
|
|
|
|
mc.shift();
|
|
|
|
|
|
|
|
assert_eq!(mc.history[mc.history.len() - 1].len(), 10);
|
|
|
|
|
|
|
|
// Shift and delete the messages
|
|
|
|
mc.shift();
|
|
|
|
assert_eq!(mc.history[mc.history.len() - 1].len(), 0);
|
|
|
|
assert_eq!(mc.history[0].len(), 0);
|
|
|
|
assert_eq!(mc.msgs.len(), 0);
|
|
|
|
}
|
|
|
|
}
|