Any implementations/alternatives for connmgr from go-libp2p in rust-libp2p?

[harsh4786]

I was looking for Connection Manager implementation that’s already available in go-libp2p but couldn’t find it in the rust-libp2p crate, any workarounds for this? Im trying to port over some go implementation of my custom protocol in rust

[dariusc93]

At the moment the only thing close would be the connection limiter. rust-libp2p does have a form of connection management by which any connections that are not marked with keepAlive::Yes (or when KeepAlive::Until duration is up) would close after a specific amount of time, though this really varies since most protocols would compute such value to determine if it should be kept alive or not (this may change in the future though - see #4121, #4161, and #3844). You could make your own form of a connection manager behaviour by tracking activities from protocols emitting events and emitting some form of event back to the behaviour in which it would mark the connection based on different things like priority, importance, etc., and tag the connection handler so it would keep it alive (based on some determined value) and once you hit a specific connection limit, you could scan through the connections and any that are not marked or of least importance you could begin to close. Giving example, if a node with a 300 connection limited is subscribed to a pubsub topic and say 200 peers subscribed, you could guard those connections so it doesnt close but say there are an additional 200 connections made to said node, your behaviour would run a task to scan through any guarded connections and those that are not guarded you can close). Do note though this does not stop other protocols or connection handlers from closing the connection (thought for handlers, I recall a discussion about removing the event to close a connection from the handler and leave that up to the behaviour).

Ideally though, I would like to see this more in rust-libp2p and pretty sure that may come in due time.

[thomaseizinger]

I am not entirely sure how the connection manager in go-libp2p works, but there are a variety of ways of how you can control connections in rust-libp2p:

• Allow/block lists: https://docs.rs/libp2p/latest/libp2p/allow_block_list/index.html
• By number of connections: https://docs.rs/libp2p/latest/libp2p/connection_limits/struct.ConnectionLimits.html
• Based on memory-consumption is in the works: feat: memory based connection limits #4281
• Via your own implementation of NetworkBehaviour. See any of the three above for some inspiration, it is quite easy really.
• Based on your own logic via:
  • https://docs.rs/libp2p/latest/libp2p/struct.Swarm.html#method.disconnect_peer_id
  • https://docs.rs/libp2p/latest/libp2p/struct.Swarm.html#method.close_connection

As @dariusc93 already mentioned, each protocol itself also defines how long it needs each connection to be alive. If all protocols say KeepAlive::No, then the connection is closed automatically.

Hope this helps!

Let us know if you think that a certain usecase isn't covered here and we'll see to accommodate it :)

[dariusc93]

I would have to go back and scan through go-libp2p for actual confirmation but going from the top of my head, one would need to tag the peer with a name and an associated weight, which I guess would act more as a given priority. When the peer is done in that protocol, and it would be removed when the peer in that protocol is no longer is in used (eg a peer no longer has a reservation to a relay - that relay would untag that peer connection). This "tagging" protects the peer, similar to how the keep-alive protections a given connection handler, Once the connections limits hits a specific threshold it has a period where it doesnt do anything but once it does, it would begin to shed any untagged connections or connections with lower "priority". Eg, in libp2p-kad, the activity there could be of lesser weight/priority compared to gossipsub/floodsub, or relay.

In an emergency situation such as coming close or hitting file descriptor limits (which would give errors once the process hits the limit) or a OOM, it could also run and clean up the connections until its those are back under control.