Thomas Eizinger

Which transport are you using? Does this issue occur with QUIC? On TCP, we are layering many technologies together, like yamux on top of noise etc. It may be that...

> I indeed used TCP. I swapped to QUIC and now it can process about 10 times more messages before this issue returns. So raising the timeout and using QUIC...

> Why not just keep the connection open if at least one stream is active? That is the (intended) behaviour today.

I'd like to see some benchmarks that moving to `SmallVec` actually fixes this. Another problem is that we _always_ call `StreamProtocol::try_from_owned` which we can only get rid of by changing...

> Disadvantage of the fix is that the `libp2p_swarm::handler::ProtocolChange` changes from difference iterator to owned `SmallVec` since the iterator is set specific and borrowed, so that prevents me from changing...

@nazar-pc It seems there is a test-failure in `libp2p-identify` now.

> Generally I don't really understand why would you un-wrap TCP and UDP (that user didn't ask to do) and chain dummy with custom transport instead of simply replacing the...

> `only_emits_address_candidate_once_per_connection` test failed, but I'm not sure why would it from the code, looks like listen address should be present by then. The test is failing because `swarm1` doesn't...

> I do not expect to see dummy transport in logs unless configured I wonder if we can fix this by checking whether we just dialed a dummy transport. A...

> 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 to...