swarm/: NetworkBehaviour cross-communication

[mxinden]

Description

Today there is no way to send generic local and remote node information from one NetworkBehaviour to another NetworkBehaviour, apart from NetworkBehaviour::inject_new_external_addr.

Examples of such generic information could be:

• Supported protocols by the local peer.
• Supported protocols of a remote peer.
• Addresses of a remote peer.

Motivation

One example use-case is the exchange of information betweenlibp2p-identify and libp2p-kad to support Kademlia Client Mode (see https://github.com/libp2p/rust-libp2p/issues/2032).

1. libp2p-kad needs to know whether a remote peer advertises /ipfs/kad/1.0.0 via the identify protocol to decide whether to include the remote peer in its routing table or not.
2. libp2p-identify needs to know whether the local node runs in client or in server mode, i.e. supports the /ipfs/kad/1.0.0 or not.

See https://github.com/libp2p/rust-libp2p/pull/2521 which is currently blocked on this.

Proposal

Below is an initial action plan proposal based on a meeting with @MarcoPolo.

1. Proof of concept 1 (communicating remote metadata across behaviours)
   • Extend NetworkBehaviourAction with NetworkBehaviourAction::ReportRemoteMetaData, containing a delta update.
   • Add NetworkBehaviourAction::inject_remote_metadata.
   • Write a Select NetworkBehaviour which takes two NetworkBehaviour implementations and passes ReportRemoteMetaData emitted by one behaviour to the other via inject_remote_metadata.
   • Showcase how libp2p-kad can learn supported protocols of remote peers from libp2p-identify.
2. Proof of concept 2 (communicating local metadata across behaviours)
   • Extend NetworkBehaviourAction with NetworkBehaviourAction::ReportSupportedProtocol which each NetworkBehaviour emits when it supports a protocol as a listener and which is passed to other NetworkBehaviours via the Select NetworkBehaviour.
   • Showcase how remote peers can learn that libp2p-kad moved from client mode into server mode via libp2p-identify.
3. In case proof of concepts looks good, don't merge but consolidate inject_* methods into single inject_event method with a single enum. Motivation here is to not have yet another inject_*** method on NetworkBehaviour.
4. Adjust proof of concepts, implement Select behaviour logic in libp2p-swarm-derive and merge.
5. Add method on Swarm (e.g. add_remote_metadata) which would call NetworkBehaviour::inject_event(Event::RemoteMetaData) on the root NetworkBehaviour.
6. Design AddressBook type which each NetworkBehaviour can instantiate and pass a reference from inject_event into to track peer metadata.

Open questions

Are you planning to do it yourself in a pull request?

No, or at least not any time soon.