Thomas Eizinger

> > To be clear, this is only really an issue with logs (and probably not related to dummy transport now that I think about it) that happens when trying...

> I'm not that familiar with what makes each connection or protocol idle vs what keeps them alive (we recently discusse Ping in #4950 but there are more) -- so...

We've landed some big internal changes to `request-response` recently: https://github.com/libp2p/rust-libp2p/pull/3914. Can you retest with latest master whether or not that still happens?

> Hi, I am facing the same errors when running our [Filecoin Rust client](https://github.com/ChainSafe/forest) in debug mode (using `libp2p-request-response-0.26.1` if that helps). Have you tried re-ordering your behaviours to have...

I don't think (1) is a suitable option as it makes it impossible to implement block lists for example. In combination with a default, non-zero idle timeout, perhaps just passing...

30 seconds seems like a lot to me. The main usecase that we talked about yesterday was to be able to initiate protocols with peers from _outside_ the `Swarm` based...

An alternative would be to entirely remove auto-closing and instead emit an event notifying the user that the connection is idle. Would that perhaps be useful?

> > An alternative would be to entirely remove auto-closing and instead emit an event notifying the user that the connection is idle. Would that perhaps be useful? > >...

I find it quite difficult to gauge what would be considered a bigger annoyance / "rust-libp2p"-ism: - Auto-closing connections when they are idle (regardless how long the timeout is) -...

On @mxinden kademlia-exporter node, a single connection uses about 300kb. I'd expect an idle connection, even with more protocols enabled to not consume much more than that because the presence...