Max Inden

I am in favor of @thomaseizinger suggestion above. That said I will not get to this any time soon. In case someone wants to take this over, let us know.

> I had a play around with this and pushed a little test harness with a docker container to test the behaviour for when we run out of file descriptors....

> If you are running out of FD you can't accept new connections anyway? Even though you might not be able to accept new connections in such case, I think...

Closing here given that https://github.com/libp2p/rust-libp2p/pull/2922/ already adds Subspace to the project list. @nazar-pc please comment in case I am missing something.

> I have a patch that just removes the parallel version, which is the simplest version. I am not sure how it could be avoided to not use `ls`. So...

Thanks for reporting this panic @dariusc93. The root of the issue is here: https://github.com/libp2p/rust-libp2p/blob/2c739e9bdb2c51199b7ade7f3aa0cb65671e5721/swarm/src/lib.rs#L538 When we hit the connection limit, we report the issue to the `NetworkBehaviour`s without a `PeerId`...

> @dariusc93 could you validate the above and propose a patch in case it resolves your issue? @dariusc93 want to create a pull request? :innocent:

Given that https://github.com/libp2p/rust-libp2p/pull/2928 is merged I am closing here. Thanks @dariusc93!

I find this more intuitive looking at `ConnectionHandler` only. Though in the greater picture, including `NetworkBehaviour`, it is inconsistent with `NetworkBehaviour::OutEvent`.

> Related to this: What do you think about renaming `NetworkBehaviour::inject_event` -> `::inject_handler_msg` With https://github.com/libp2p/rust-libp2p/pull/2867/ `NetworkBehaviour::inject_event` would move to `NetworkBehaviour::on_event` via `InEvent::ConnectionHandler`. (Where `InEvent` would be renamed to `FromSwarm` with...