即使将对等节点添加到预留节点中,连接也会断开。

问题:连接会被丢弃,即使将对等节点添加到预留节点中。 环境:我们是 AlephZero,正在开发一个基于 AlephBFT 的基质节点。我们的运行时间很短(1 秒),并且使用 AURA。否则,我们的规格非常标准。目前我们依赖 polkadot-v0.9.13 分支。 我们在基质网络之上构建了自己的网络层,以确保验证者之间的直接连接。我们的网络有两个协议/对等集:通用和验证者。前者允许每两个节点之间的通信和流言蜚语(无论它们的角色如何)。如果它们在通用协议中认证自己为某个会话的验证者,则将它们添加到验证者对等集中作为预留节点。 最近,在连接 104 个节点(100 个非验证者和 4 个验证者)的测试中,我们发现即使我们始终将每个可能的对等节点添加为预留节点,其中一些节点仍然无法保持连接。另一方面,同步块工作,这表明默认的基质协议正常工作。 我附上了 2 个验证者日志的 grep(对每个其他对等节点的 grep 都是健康的,或者与下面的日志完全相同): 1. 连接失败的非验证者 2. 其他验证者 1 个日志显示,我们正在尝试大约 50 次连接此类节点。2 个日志是奇怪的,看起来我们连接了某些对等节点,然后断开连接并永远不重试。这些结论是基于“sub-libp2p”目标的行。 由于验证者无法在通用对等集中连接到彼此,因此他们永远不会连接到验证者对等集,导致最终化过程根本不会启动。 当我们发现此问题时,我们尝试稍微改变我们的逻辑。我们停止将每个节点添加为预留节点到通用对等集中,并开始仅对那些能够认证自己为验证者的节点这样做(如果是,则将它们添加为预留节点到两个对等集中)。但问题进一步恶化:在本版本中,没有人能够向任何人发送消息,因为对任何对等节点和任何协议的 sc_network::service::network.notification_sender(peer, protocol) 调用都会导致错误。 1. 对预留对等节点的数量或添加它们的条件是否有任何限制? 2. 我们的协议为什么不能接收消息,而默认网络却可以,即块正在同步? 3. 是否可以为非预留对等节点创建通知发送器?