rust-libp2p Floodsub 协议演进全解从 0.19 到 0.48 的变更史、去重机制与依赖迁移【免费下载链接】rust-libp2pThe Rust Implementation of the libp2p networking stack.项目地址: https://gitcode.com/GitHub_Trending/ru/rust-libp2pFloodsub 是 libp2p 生态中最朴素的 pub/sub 协议不做消息路由收敛、不做历史缓存只按谁订阅了主题就把消息转发给谁的规则做全量洪泛flooding。本文以 protocols/floodsub/CHANGELOG.md 为骨架梳理libp2p-floodsub从 0.19 到 0.48 的关键演进脉络并对照 protocols/floodsub 下的源码与 Cargo 配置讲清去重缓存实现、protobuf 编解码迁移prost ↔ quick-protobuf、MSRV 策略以及消息传播模型等底层细节帮助你理解这个协议 crate 的历史包袱与当前实现。读完本文你可以快速判断在什么场景下选择 Floodsub以及 0.48.0 的代码在去重、发布与转发上到底做了什么。Floodsub 是什么协议定位与适用场景Floodsub 对应 libp2p pubsub 规范中的泛洪实现。在 protocols/floodsub/src/lib.rs 的文档注释中其实现依据是 libp2p specs 仓库中的 pubsub README即floodsub协议规范。与同为 pubsub 家族的 Gossipsub 相比Floodsub 的算法极其简单每个节点维护一组订阅的主题Topic当节点收到一条消息时把消息转发给所有已订阅该主题且在本节点通信列表内的邻居不做消息去重之外的任何优化不维护 mesh、不计算 peer score、不做机会性转发。因此它的典型适用场景是网络规模小、拓扑简单、对带宽不敏感的原型验证与内部测试。从仓库实际使用看libp2p/src/lib.rs 通过floodsubfeature 将libp2p_floodsub以libp2p::floodsub的名字重导出方便上层应用一行引入。版本演进时间线0.19 → 0.48CHANGELOG.md 完整记录了从 0.19.1 到 0.48.0 的变更。大致可以分为三条主线1. 依赖与工具链升级贯穿始终0.40.0rand升级到 0.8、quickcheck升级到 1随后同步升级libp2p-corev0.37.0 与libp2p-swarmv0.40.0。0.42.1从prost迁移到quick-protobuf移除对protoc编译器的依赖。0.38.0prost从 0.10 升到 0.11该版本不再自动安装protoc因此本地需要自行安装 protoc。0.43.0MSRV 提升到 1.650.41.0时曾将rust-version修正为真实的 1.62.0。0.48.0MSRV 再次提升到1.88.0对应 PR 6273并从quick-protobuf回退迁移到prost对应 PR 6363。2. 去重机制演进0.48.0 的核心0.48.0 之前代码使用cuckoofilter布谷鸟过滤器对重复消息去重。0.48.0 将重复消息过滤的 cuckoo filter 替换为有界 LRU 缓存hashlink::LruCache同时移除了rand0.7.3 这个旧依赖见 issue 6419。3. API 与行为调整0.44.0publish改为接收data: impl IntoBytes从类型层面避免发布消息时发生不必要的拷贝与分配。0.41.0将NetworkBehaviour实现从旧的inject_*系列方法迁移到新的on_*方法族。0.34.0合并NetworkBehaviour中成对的inject_*方法PR 2445。0.33.0迁移到 Rust 2021 edition并只向目标 peertarget_peers传播消息而不是发给所有已连接节点PR 2360。0.30.0FloodsubDecodeError::ReadError的类型从upgrade::ReadOneError改为std::io::Error。0.31.0libp2p-core的默认 feature 变为可选便于裁剪依赖。0.47.0按 discussion 2174 的命名约定重命名了类型对应 PR 5855并同步libp2p-swarmv0.47.0。注意0.45.0、0.46.0 等版本的变更记录只有一行注释如 Update to libp2p-swarm v0.45.0说明这些版本纯粹是跟随libp2p-swarm/libp2p-core的联动发布floodsub 自身没有行为变化。0.48.0 深度解析去重缓存替换 cuckoo filter为什么替换旧的 cuckoo filter 方案存在两个问题一是引入了rand0.7.3 这一旧版本依赖与工作区其他 crate 的rand版本不一致二是布谷鸟过滤器本身适合集合成员判断而 floodsub 需要的是按时间淘汰的最近接收消息——消息只会在很短的时间窗口内重复到达需要的是一个能自动淘汰旧条目的结构。0.48.0 的选择是hashlink::LruCache。源码验证在 protocols/floodsub/src/layer.rs 中// Limit the number of received messages retained for deduplication. const RECEIVED_CACHE_CAPACITY: usize 1 16;Behaviour内部维护received: LruCacheFloodsubMessage, (),容量被硬编码为1 1665536 条。收到消息时先查缓存// Use self.received to skip the messages that we have already received in the past. if self.received.insert(message.clone(), ()).is_some() { continue; }LruCache::insert返回旧值时说明这条消息此前已经处理过直接跳过否则视为新消息继续分发与转发。配合smallvec、fnvFnvHashSet等容器热路径上避免了任何 hash 开销以外的额外分配。同时 protocols/floodsub/Cargo.toml 中rand仍保留工作区版本因为发布消息仍需要用随机数生成序列号被移除的只是旧的rand 0.7.3。cuckoofilter已不在依赖列表中。序列号随机 20 字节防攻击在 layer.rs 的publish_many_inner中sequence_number: rand::random::[u8; 20]().to_vec(),源码注释给出了明确的安全理由如果序列号可预测攻击者可以预先构造同序列号的报文在网络中吸收合法消息去重机制会误判为重复。因此每次发布使用 20 字节随机数把去重键的不可预测性作为安全边界的一部分。编解码层prost 与 quick-protobuf 的两次往返消息格式FloodsubRpc在 wire 上的编码由 generated/rpc.proto 定义proto2 语法message RPC { repeated SubOpts subscriptions 1; repeated Message publish 2; message SubOpts { optional bool subscribe 1; // subscribe or unsubscribe optional string topic_id 2; } } message Message { optional bytes from 1; optional bytes data 2; optional bytes seqno 3; repeated string topic_ids 4; }对应的 prost 生成代码在 generated/floodsub.pb.rs由 generated/mod.rs 引入并在 lib.rs 中通过proto私有模块包装后对外隐藏。迁移路径还原0.42.1从prost迁到quick-protobufPR 3312目标是移除protoc依赖、简化构建0.48.0又回退到prostPR 6363。当前仓库的 Cargo.toml 中依赖为prost与prost-codec工作区版本并使用include!(generated/mod.rs)方式内嵌生成代码——这与仓库内 misc/prost-codec 提供的编解码器配合使用工作区统一走 prost 生态。这个反复说明了一个现实约束protobuf 生成器的选择会影响整个工作区的构建工具链是否需要protoc、生成代码是否内嵌、是否引入额外的 build 脚本对多 crate 工作区而言统一往往比单 crate 最优更重要。长度限制与单帧语义protocols/floodsub/src/protocol.rs 定义了协议名与最大消息长度const MAX_MESSAGE_LEN_BYTES: usize 2048; const PROTOCOL_NAME: StreamProtocol StreamProtocol::new(/floodsub/1.0.0);入站与出站方向都通过prost_codec::Codec::proto::RPC::new(MAX_MESSAGE_LEN_BYTES)构造Framed编解码器即每条 RPC 帧上限 2048 字节。连接升级使用InboundUpgrade/OutboundUpgrade配合OneShotHandler一次连接只交换一轮 RPC协议名固定为/floodsub/1.0.0。错误类型FloodsubErrorprotocol.rs包含三类错误InvalidPeerId消息中from字段无法解析为PeerIdProtobufErrorprotobuf 解码失败ReadError从 socket 读取失败。0.30.0 起该变体直接携带std::io::Error比此前的upgrade::ReadOneError更贴近底层、更方便直接透传。传播模型target_peers 与订阅跟踪0.33.0 的行为修正0.33.0PR 2360把向所有已连接 peer 传播改为只向通信列表内的 peer 传播。这在源码中体现为Behaviour的两个数据结构target_peers: FnvHashSetPeerId通过add_node_to_partial_view/remove_node_from_partial_view维护的通信名单connected_peers: HashMapPeerId, SmallVec[Topic; 8]每个已连接 peer 订阅了哪些主题。在publish_many_inner与on_connection_handler_event的转发循环中都有同一道双重过滤// Peer must be in a communication list. if !self.target_peers.contains(peer_id) { continue; } // Peer must be subscribed for the topic. if !sub_topic.iter().any(|t| message.topics.iter().any(|u| t u)) { continue; }即只有同时满足在通信名单内且订阅了该主题两个条件的节点才会收到消息。订阅同步与重连on_connection_established里新连接建立后若对方在target_peers中会把本地全部subscribed_topics以SubscribeRPC 推送过去subscribe/unsubscribe方法也会向所有已连接 peer 广播订阅变化。断开连接时on_connection_closed只要该 peer 仍在target_peers中就会自动发起重连ToSwarm::Dial——源码注释明确写道We can be disconnected by the remote in case of inactivity for example, so we always try to reconnect。消息生命周期收到远端FloodsubRpc后的处理顺序on_connection_handler_event逐个处理subscriptions更新connected_peers中该 peer 的主题集合并向用户发出Event::Subscribed/Event::Unsubscribed逐个处理messages先查receivedLRU 缓存去重若命中本地订阅主题则上抛Event::Message随后把消息追加进按 peer 聚合的rpcs_to_dispatch统一批量转发。Event枚举layer.rs只有三个变体Message、Subscribed { peer_id, topic }、Unsubscribed { peer_id, topic }是上层应用唯一需要消费的事件类型。API 使用要点以 0.48.0 为准配置protocols/floodsub/src/lib.rs 定义了Configpub struct Config { /// Peer id of the local node. Used for the source of the messages that we publish. pub local_peer_id: PeerId, /// true if messages published by local node should be propagated as messages received from /// the network, false by default. pub subscribe_local_messages: bool, }local_peer_id本地节点 PeerId作为发布消息的sourcesubscribe_local_messages默认false设为true后本地发布的消息也会以Event::Message的形式回抛给应用注意去重缓存会先记录这条消息因此不会重复上抛。Config::new(local_peer_id)提供默认配置Behaviour::from_config(config)构造行为Behaviour::new(local_peer_id)则直接使用默认配置。旧命名FloodsubConfig/Floodsub/FloodsubEvent均以#[deprecated]形式保留为类型别名新代码应使用Config/Behaviour/Event。核心方法方法行为add_node_to_partial_view(peer_id)把节点加入通信名单若已连接则同步本地订阅否则发起拨号remove_node_from_partial_view(peer_id)从通信名单移除subscribe(topic) - bool订阅主题并广播订阅 RPC重复订阅返回falseunsubscribe(topic) - bool取消订阅并广播退订 RPC未订阅返回falsepublish(topic, data)发布单主题消息要求本地已订阅该主题否则静默丢弃publish_any(topic, data)发布单主题消息不要求本地已订阅publish_many(topics, data)多主题发布同样要求本地至少订阅其中一个主题publish_many_any(topics, data)多主题发布无订阅要求publish系列的底层都汇入publish_many_inner生成FloodsubMessagesource 为本地 PeerId、data 为Bytes、seqno 为随机 20 字节、topics 为传入列表先写入本地received缓存再按通信名单 主题匹配规则分发给每个邻居。消息与主题类型FloodsubMessagesource: PeerId、data: Bytes、sequence_number: Vecu8、topics: VecTopic。一条消息可同时属于多个主题Topicprotocols/floodsub/src/topic.rs字符串包装类型Topic::new(name)构造、id()取回字符串实现Clone PartialEq Eq HashFloodsubRpc一次 RPC 携带messages与subscriptions两组数据出站时由into_rpc()编码为 protobufRPC。如何在你的 crate 中接入依赖在工作区中使用libp2p-floodsub 0.48当前仓库版本见 protocols/floodsub/Cargo.toml若使用聚合 crate直接启用libp2p的floodsubfeature 即可通过libp2p::floodsub访问见 libp2p/src/lib.rs。构建行为0.48.0 使用 prost 生态生成代码已内嵌include!因此构建时不需要安装protoc若回溯到 0.42.1 与 0.38.0 之间依赖 quick-protobuf 或 prost 0.11 的版本则需要本地具备protoc详见上文版本时间线。最小用法use libp2p::floodsub::{Behaviour, Config, Topic}; let config Config::new(local_peer_id); let mut behaviour Behaviour::from_config(config); let topic Topic::new(chat-room); behaviour.subscribe(topic.clone()); behaviour.publish(topic, hello.as_bytes().to_vec());事件处理在SwarmEvent::Behaviour(Event::Message(msg))中消费消息对端Subscribed/Unsubscribed事件同样通过 behaviour 事件流获得。小结从 0.19 一路到 0.48libp2p-floodsub的演进可以浓缩为三件事跟随 libp2p-core/swarm 的版本联动、protobuf 生成器在 prost 与 quick-protobuf 之间的往返取舍、以及把消息去重从 cuckoo filter 换成更贴合时间窗口去重语义的有界 LRU 缓存。对使用方而言最有感知的变化集中在 0.44.0IntoBytes发布 API、0.33.0只向通信名单传播与 0.48.0去重实现与 MSRV 1.88。如果只是想快速做小规模 pub/sub 原型0.48.0 的 floodsub 足够简单直接当网络规模扩大、需要带宽控制与消息收敛时再考虑迁移到同一仓库下基于 mesh 的 protocols/gossipsub 实现。【免费下载链接】rust-libp2pThe Rust Implementation of the libp2p networking stack.项目地址: https://gitcode.com/GitHub_Trending/ru/rust-libp2p创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/17 20:12:03 · 阅读 1.2k rust-libp2p Floodsub 协议演进全解：从 0.19 到 0.48 的变更史、去重机制与依赖迁移
rust-libp2p Floodsub 协议演进全解从 0.19 到 0.48 的变更史、去重机制与依赖迁移【免费下载链接】rust-libp2pThe Rust Implementation of the libp2p networking stack.项目地址: https://gitcode.com/GitHub_Trending/ru/rust-libp2pFloodsub 是 libp2p 生态中最朴素的 pub/sub 协议不做消息路由收敛、不做历史缓存只按谁订阅了主题就把消息转发给谁的规则做全量洪泛flooding。本文以 protocols/floodsub/CHANGELOG.md 为骨架梳理libp2p-floodsub从 0.19 到 0.48 的关键演进脉络并对照 protocols/floodsub 下的源码与 Cargo 配置讲清去重缓存实现、protobuf 编解码迁移prost ↔ quick-protobuf、MSRV 策略以及消息传播模型等底层细节帮助你理解这个协议 crate 的历史包袱与当前实现。读完本文你可以快速判断在什么场景下选择 Floodsub以及 0.48.0 的代码在去重、发布与转发上到底做了什么。Floodsub 是什么协议定位与适用场景Floodsub 对应 libp2p pubsub 规范中的泛洪实现。在 protocols/floodsub/src/lib.rs 的文档注释中其实现依据是 libp2p specs 仓库中的 pubsub README即floodsub协议规范。与同为 pubsub 家族的 Gossipsub 相比Floodsub 的算法极其简单每个节点维护一组订阅的主题Topic当节点收到一条消息时把消息转发给所有已订阅该主题且在本节点通信列表内的邻居不做消息去重之外的任何优化不维护 mesh、不计算 peer score、不做机会性转发。因此它的典型适用场景是网络规模小、拓扑简单、对带宽不敏感的原型验证与内部测试。从仓库实际使用看libp2p/src/lib.rs 通过floodsubfeature 将libp2p_floodsub以libp2p::floodsub的名字重导出方便上层应用一行引入。版本演进时间线0.19 → 0.48CHANGELOG.md 完整记录了从 0.19.1 到 0.48.0 的变更。大致可以分为三条主线1. 依赖与工具链升级贯穿始终0.40.0rand升级到 0.8、quickcheck升级到 1随后同步升级libp2p-corev0.37.0 与libp2p-swarmv0.40.0。0.42.1从prost迁移到quick-protobuf移除对protoc编译器的依赖。0.38.0prost从 0.10 升到 0.11该版本不再自动安装protoc因此本地需要自行安装 protoc。0.43.0MSRV 提升到 1.650.41.0时曾将rust-version修正为真实的 1.62.0。0.48.0MSRV 再次提升到1.88.0对应 PR 6273并从quick-protobuf回退迁移到prost对应 PR 6363。2. 去重机制演进0.48.0 的核心0.48.0 之前代码使用cuckoofilter布谷鸟过滤器对重复消息去重。0.48.0 将重复消息过滤的 cuckoo filter 替换为有界 LRU 缓存hashlink::LruCache同时移除了rand0.7.3 这个旧依赖见 issue 6419。3. API 与行为调整0.44.0publish改为接收data: impl IntoBytes从类型层面避免发布消息时发生不必要的拷贝与分配。0.41.0将NetworkBehaviour实现从旧的inject_*系列方法迁移到新的on_*方法族。0.34.0合并NetworkBehaviour中成对的inject_*方法PR 2445。0.33.0迁移到 Rust 2021 edition并只向目标 peertarget_peers传播消息而不是发给所有已连接节点PR 2360。0.30.0FloodsubDecodeError::ReadError的类型从upgrade::ReadOneError改为std::io::Error。0.31.0libp2p-core的默认 feature 变为可选便于裁剪依赖。0.47.0按 discussion 2174 的命名约定重命名了类型对应 PR 5855并同步libp2p-swarmv0.47.0。注意0.45.0、0.46.0 等版本的变更记录只有一行注释如 Update to libp2p-swarm v0.45.0说明这些版本纯粹是跟随libp2p-swarm/libp2p-core的联动发布floodsub 自身没有行为变化。0.48.0 深度解析去重缓存替换 cuckoo filter为什么替换旧的 cuckoo filter 方案存在两个问题一是引入了rand0.7.3 这一旧版本依赖与工作区其他 crate 的rand版本不一致二是布谷鸟过滤器本身适合集合成员判断而 floodsub 需要的是按时间淘汰的最近接收消息——消息只会在很短的时间窗口内重复到达需要的是一个能自动淘汰旧条目的结构。0.48.0 的选择是hashlink::LruCache。源码验证在 protocols/floodsub/src/layer.rs 中// Limit the number of received messages retained for deduplication. const RECEIVED_CACHE_CAPACITY: usize 1 16;Behaviour内部维护received: LruCacheFloodsubMessage, (),容量被硬编码为1 1665536 条。收到消息时先查缓存// Use self.received to skip the messages that we have already received in the past. if self.received.insert(message.clone(), ()).is_some() { continue; }LruCache::insert返回旧值时说明这条消息此前已经处理过直接跳过否则视为新消息继续分发与转发。配合smallvec、fnvFnvHashSet等容器热路径上避免了任何 hash 开销以外的额外分配。同时 protocols/floodsub/Cargo.toml 中rand仍保留工作区版本因为发布消息仍需要用随机数生成序列号被移除的只是旧的rand 0.7.3。cuckoofilter已不在依赖列表中。序列号随机 20 字节防攻击在 layer.rs 的publish_many_inner中sequence_number: rand::random::[u8; 20]().to_vec(),源码注释给出了明确的安全理由如果序列号可预测攻击者可以预先构造同序列号的报文在网络中吸收合法消息去重机制会误判为重复。因此每次发布使用 20 字节随机数把去重键的不可预测性作为安全边界的一部分。编解码层prost 与 quick-protobuf 的两次往返消息格式FloodsubRpc在 wire 上的编码由 generated/rpc.proto 定义proto2 语法message RPC { repeated SubOpts subscriptions 1; repeated Message publish 2; message SubOpts { optional bool subscribe 1; // subscribe or unsubscribe optional string topic_id 2; } } message Message { optional bytes from 1; optional bytes data 2; optional bytes seqno 3; repeated string topic_ids 4; }对应的 prost 生成代码在 generated/floodsub.pb.rs由 generated/mod.rs 引入并在 lib.rs 中通过proto私有模块包装后对外隐藏。迁移路径还原0.42.1从prost迁到quick-protobufPR 3312目标是移除protoc依赖、简化构建0.48.0又回退到prostPR 6363。当前仓库的 Cargo.toml 中依赖为prost与prost-codec工作区版本并使用include!(generated/mod.rs)方式内嵌生成代码——这与仓库内 misc/prost-codec 提供的编解码器配合使用工作区统一走 prost 生态。这个反复说明了一个现实约束protobuf 生成器的选择会影响整个工作区的构建工具链是否需要protoc、生成代码是否内嵌、是否引入额外的 build 脚本对多 crate 工作区而言统一往往比单 crate 最优更重要。长度限制与单帧语义protocols/floodsub/src/protocol.rs 定义了协议名与最大消息长度const MAX_MESSAGE_LEN_BYTES: usize 2048; const PROTOCOL_NAME: StreamProtocol StreamProtocol::new(/floodsub/1.0.0);入站与出站方向都通过prost_codec::Codec::proto::RPC::new(MAX_MESSAGE_LEN_BYTES)构造Framed编解码器即每条 RPC 帧上限 2048 字节。连接升级使用InboundUpgrade/OutboundUpgrade配合OneShotHandler一次连接只交换一轮 RPC协议名固定为/floodsub/1.0.0。错误类型FloodsubErrorprotocol.rs包含三类错误InvalidPeerId消息中from字段无法解析为PeerIdProtobufErrorprotobuf 解码失败ReadError从 socket 读取失败。0.30.0 起该变体直接携带std::io::Error比此前的upgrade::ReadOneError更贴近底层、更方便直接透传。传播模型target_peers 与订阅跟踪0.33.0 的行为修正0.33.0PR 2360把向所有已连接 peer 传播改为只向通信列表内的 peer 传播。这在源码中体现为Behaviour的两个数据结构target_peers: FnvHashSetPeerId通过add_node_to_partial_view/remove_node_from_partial_view维护的通信名单connected_peers: HashMapPeerId, SmallVec[Topic; 8]每个已连接 peer 订阅了哪些主题。在publish_many_inner与on_connection_handler_event的转发循环中都有同一道双重过滤// Peer must be in a communication list. if !self.target_peers.contains(peer_id) { continue; } // Peer must be subscribed for the topic. if !sub_topic.iter().any(|t| message.topics.iter().any(|u| t u)) { continue; }即只有同时满足在通信名单内且订阅了该主题两个条件的节点才会收到消息。订阅同步与重连on_connection_established里新连接建立后若对方在target_peers中会把本地全部subscribed_topics以SubscribeRPC 推送过去subscribe/unsubscribe方法也会向所有已连接 peer 广播订阅变化。断开连接时on_connection_closed只要该 peer 仍在target_peers中就会自动发起重连ToSwarm::Dial——源码注释明确写道We can be disconnected by the remote in case of inactivity for example, so we always try to reconnect。消息生命周期收到远端FloodsubRpc后的处理顺序on_connection_handler_event逐个处理subscriptions更新connected_peers中该 peer 的主题集合并向用户发出Event::Subscribed/Event::Unsubscribed逐个处理messages先查receivedLRU 缓存去重若命中本地订阅主题则上抛Event::Message随后把消息追加进按 peer 聚合的rpcs_to_dispatch统一批量转发。Event枚举layer.rs只有三个变体Message、Subscribed { peer_id, topic }、Unsubscribed { peer_id, topic }是上层应用唯一需要消费的事件类型。API 使用要点以 0.48.0 为准配置protocols/floodsub/src/lib.rs 定义了Configpub struct Config { /// Peer id of the local node. Used for the source of the messages that we publish. pub local_peer_id: PeerId, /// true if messages published by local node should be propagated as messages received from /// the network, false by default. pub subscribe_local_messages: bool, }local_peer_id本地节点 PeerId作为发布消息的sourcesubscribe_local_messages默认false设为true后本地发布的消息也会以Event::Message的形式回抛给应用注意去重缓存会先记录这条消息因此不会重复上抛。Config::new(local_peer_id)提供默认配置Behaviour::from_config(config)构造行为Behaviour::new(local_peer_id)则直接使用默认配置。旧命名FloodsubConfig/Floodsub/FloodsubEvent均以#[deprecated]形式保留为类型别名新代码应使用Config/Behaviour/Event。核心方法方法行为add_node_to_partial_view(peer_id)把节点加入通信名单若已连接则同步本地订阅否则发起拨号remove_node_from_partial_view(peer_id)从通信名单移除subscribe(topic) - bool订阅主题并广播订阅 RPC重复订阅返回falseunsubscribe(topic) - bool取消订阅并广播退订 RPC未订阅返回falsepublish(topic, data)发布单主题消息要求本地已订阅该主题否则静默丢弃publish_any(topic, data)发布单主题消息不要求本地已订阅publish_many(topics, data)多主题发布同样要求本地至少订阅其中一个主题publish_many_any(topics, data)多主题发布无订阅要求publish系列的底层都汇入publish_many_inner生成FloodsubMessagesource 为本地 PeerId、data 为Bytes、seqno 为随机 20 字节、topics 为传入列表先写入本地received缓存再按通信名单 主题匹配规则分发给每个邻居。消息与主题类型FloodsubMessagesource: PeerId、data: Bytes、sequence_number: Vecu8、topics: VecTopic。一条消息可同时属于多个主题Topicprotocols/floodsub/src/topic.rs字符串包装类型Topic::new(name)构造、id()取回字符串实现Clone PartialEq Eq HashFloodsubRpc一次 RPC 携带messages与subscriptions两组数据出站时由into_rpc()编码为 protobufRPC。如何在你的 crate 中接入依赖在工作区中使用libp2p-floodsub 0.48当前仓库版本见 protocols/floodsub/Cargo.toml若使用聚合 crate直接启用libp2p的floodsubfeature 即可通过libp2p::floodsub访问见 libp2p/src/lib.rs。构建行为0.48.0 使用 prost 生态生成代码已内嵌include!因此构建时不需要安装protoc若回溯到 0.42.1 与 0.38.0 之间依赖 quick-protobuf 或 prost 0.11 的版本则需要本地具备protoc详见上文版本时间线。最小用法use libp2p::floodsub::{Behaviour, Config, Topic}; let config Config::new(local_peer_id); let mut behaviour Behaviour::from_config(config); let topic Topic::new(chat-room); behaviour.subscribe(topic.clone()); behaviour.publish(topic, hello.as_bytes().to_vec());事件处理在SwarmEvent::Behaviour(Event::Message(msg))中消费消息对端Subscribed/Unsubscribed事件同样通过 behaviour 事件流获得。小结从 0.19 一路到 0.48libp2p-floodsub的演进可以浓缩为三件事跟随 libp2p-core/swarm 的版本联动、protobuf 生成器在 prost 与 quick-protobuf 之间的往返取舍、以及把消息去重从 cuckoo filter 换成更贴合时间窗口去重语义的有界 LRU 缓存。对使用方而言最有感知的变化集中在 0.44.0IntoBytes发布 API、0.33.0只向通信名单传播与 0.48.0去重实现与 MSRV 1.88。如果只是想快速做小规模 pub/sub 原型0.48.0 的 floodsub 足够简单直接当网络规模扩大、需要带宽控制与消息收敛时再考虑迁移到同一仓库下基于 mesh 的 protocols/gossipsub 实现。【免费下载链接】rust-libp2pThe Rust Implementation of the libp2p networking stack.项目地址: https://gitcode.com/GitHub_Trending/ru/rust-libp2p创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考