Gossipsub forwards messages in fully connected small mesh

[RustMania]

Recently I observed that network packets in gossipsub are not delivered occasionally. This happens mostly on slow VMs with low CPU resource. My application uses a protocol , where most of messages are broadcast to small fixed amount of parties, e.g 3-4. The protocol stopped occasionally after a timeout, because some of broadcasts did not seem to reach the destination.

After close examination of inputs, I found that a node subscribed to a topic receives all messages from that topic, however sometimes Gossipsub forwards messages via another node, even in very small fully connected mesh. As a result, the field propagation_source in GossipsubEvent::Message will be set to the peer id of a forwarder. Therefore the field is useless to identify a message sender.
To fix the problem I looked into the GossipsubMessage, where I found the field source, which is Option, but it seems to be set all the time to correct source id, at least for now and in my case.

I guess the forwarding is a feature of Gossipsub architecture aimed to build sparse meshes, so the field in the Event enum is just an identity of the forwarder. If message is forwarded and the field in GossipsubMessage is set to None, it leaves receiver w/o chance to identify a sender. Under what condition the field becomes None?

Finally, the floodsub protocol must be significantly simpler than gossipsub , just guessing from the implementation.
Can the entire problem with the identification of the source be avoided by using floodsub instead?

[thomaseizinger]

Under what condition the field becomes None?

See this snippet:

rust-libp2p/protocols/gossipsub/src/behaviour.rs

Lines 2762 to 2850 in c32f03c

	/// Constructs a [`RawGossipsubMessage`] performing message signing if required.
	pub(crate) fn build_raw_message(
	&self,
	topic: TopicHash,
	data: Vec<u8>,
	) -> Result<RawGossipsubMessage, PublishError> {
	match &self.publish_config {
	PublishConfig::Signing {
	ref keypair,
	author,
	inline_key,
	} => {
	// Build and sign the message
	let sequence_number: u64 = rand::random();
	let signature = {
	let message = rpc_proto::Message {
	from: Some(author.clone().to_bytes()),
	data: Some(data.clone()),
	seqno: Some(sequence_number.to_be_bytes().to_vec()),
	topic: topic.clone().into_string(),
	signature: None,
	key: None,
	};
	let mut buf = Vec::with_capacity(message.encoded_len());
	message
	.encode(&mut buf)
	.expect("Buffer has sufficient capacity");
	// the signature is over the bytes "libp2p-pubsub:<protobuf-message>"
	let mut signature_bytes = SIGNING_PREFIX.to_vec();
	signature_bytes.extend_from_slice(&buf);
	Some(keypair.sign(&signature_bytes)?)
	};
	Ok(RawGossipsubMessage {
	source: Some(*author),
	data,
	// To be interoperable with the go-implementation this is treated as a 64-bit
	// big-endian uint.
	sequence_number: Some(sequence_number),
	topic,
	signature,
	key: inline_key.clone(),
	validated: true, // all published messages are valid
	})
	}
	PublishConfig::Author(peer_id) => {
	Ok(RawGossipsubMessage {
	source: Some(*peer_id),
	data,
	// To be interoperable with the go-implementation this is treated as a 64-bit
	// big-endian uint.
	sequence_number: Some(rand::random()),
	topic,
	signature: None,
	key: None,
	validated: true, // all published messages are valid
	})
	}
	PublishConfig::RandomAuthor => {
	Ok(RawGossipsubMessage {
	source: Some(PeerId::random()),
	data,
	// To be interoperable with the go-implementation this is treated as a 64-bit
	// big-endian uint.
	sequence_number: Some(rand::random()),
	topic,
	signature: None,
	key: None,
	validated: true, // all published messages are valid
	})
	}
	PublishConfig::Anonymous => {
	Ok(RawGossipsubMessage {
	source: None,
	data,
	// To be interoperable with the go-implementation this is treated as a 64-bit
	// big-endian uint.
	sequence_number: None,
	topic,
	signature: None,
	key: None,
	validated: true, // all published messages are valid
	})
	}
	}
	}

The sender can choose what to set this field to. In an untrusted environment, you can only trust it when it comes with a signature as well.

If you have a small mesh, then yes, floodsub might be a better choice. It has really good latency properties but will flood all connected peers with every incoming message (except the sender).