search

libp2p / rust-libp2p

The Rust Implementation of the libp2p networking stack.
https://libp2p.io
MIT License
4.56k stars 949 forks source link

`Gossipsub`'s substreams keep all connections alive after `idle_connection_timeout` #5190

Open dmytro-his opened 8 months ago

dmytro-his commented 8 months ago

Summary

It seems gossipsub protocol keeps active substreams for connections that exists outside the gossip-mesh. As a result, connections remain alive even after idle_connection_timeout.

This functionality appears to have changed from version v0.52.0, where gossip kept connections alive only within the mesh. Commits with relevant updates: https://github.com/libp2p/rust-libp2p/commit/fafa6bc472f6fe9501c75be6a936df2cb37e053a and https://github.com/libp2p/rust-libp2p/commit/fcd410a56c86de3b34f4896d1447ef1da959947c

Expected behavior

Gossipsub protocol should keep connections alive, but exclusively for peers within the mesh

Actual behavior

Gossipsub protocol keeps all connections alive

Relevant log output

No response

Possible Solution

Ignore gossip substreams in the connection-keep-alive algorithm. Use libp2p_swarm::stream::Stream::ignore_for_keep_alive for gossip inbound and outbound substreams.

Version

0.53.1

Would you like to work on fixing this bug ?

Maybe

dmytro-his commented 2 months ago

Hi @jxs, could you please provide feedback on this issue? Is it indeed a bug, or is this expected behavior? Also, does the proposed solution work for you?

jxs commented 2 months ago

Hi, and sorry for missing this! Currently gossipsub only keeps the substream if it is in the mesh: https://github.com/libp2p/rust-libp2p/blob/4dfc45bfec008405988edca2432c27ed5b93535f/protocols/gossipsub/src/handler.rs#L426-L428 which seems to be the opposite to what you refer on the issue right? But I think all connections should be kept alive, as gossipsub publishes messages for peers not in the mesh.