Max Inden

I am not sure I follow. You want to be able to override the generated implementation of `NetworkBehaviour::inject_connection_closed`?

If I understand your suggestion correctly, this could e.g. be useful in `libp2p-autonat` where many `NetworkBehaviour` methods simply delegate to the underlying `libp2p-request-response` `NetworkBehaviour`, while for other methods one wants...

@thomaseizinger @elenaf9 could one of you give this pull request a review?

Thanks for the review @thomaseizinger. I addressed all your comments. Let me know what you think.

Thanks for the help @thomaseizinger!

Thanks for raising this @Frederik-Baetens. I think this is a general issue across the many `NetworkBehaviour` implementations. I would rephrase it as: "Synchronous methods on `NetworkBehaviour` implementations to be used...

> Is there a design doc somewhere explaining why this design was chosen? Not aware of a design doc. The major benefit I see is flexibility. That is, you can...

We could promote something along the lines of the [file sharing example](https://github.com/libp2p/rust-libp2p/blob/master/examples/file-sharing.rs) to a proper wrapper around a `Swarm`, generic over the `NetworkBehaviour` in use.

Thanks for the detailed report @mathiversen! I think we should dig deeper into why the listening client fails to maintain the connection. Would you mind running both listening client and...

> Server (Linux 5.4.0-99-generic 112-Ubuntu SMP x86_64): > > ``` > opt: Opt { use_ipv6: None, secret_key_seed: 0, port: 4001 } > Local peer id: PeerId("12D3KooWDpJ7As7BWAwRMfu1VU2WCqNjvq387JEYKDBj4kx6nXTN") > Listening on: "/ip4/127.0.0.1/tcp/4001"...