Multiple transport support with fallbacks

[jsamol]

Hi all! 👋 I've been playing around with rust-libp2p recently, I wrote a simple application that discovers peers in the local network with mdns and then sends a simple JSON message using request-response. Technically, everything works fine, but I want to support multiple transports and this is the part that complicates it for me.

When my peer listens on multiple multiaddresses, it naturally sends all of them during the mDNS discovery phase. This means that in the mdns::Event::Discovered I get a list containing multiple entries for the same peer id. I then propagate these with Swarm::add_peer_address to my behaviours, so later I can call request_response::Behaviour::send_request to send my message to the selected peer. send_request takes only a peer id as an argument, so I can't specify which transport I want to use for this operation, which results in the message being sent multiple times to all the multiaddresses stored for the peer id.

Ideally, I'd like to specify an order of transports to try for communication, so only one is tried at a time and the next is used only as a fallback in case the first one didn't work. Is it somehow supported and I just missed it? Is it specific to this protocol only? Or should I rather handle the dialing myself to make sure only one transport is used to establish a connection with the peer?

[drHuangMHT]

That seems...odd. If you establish multiple ”physical“(tcp or udp) connection, multiple handlers will be created for each of these connections, but the behaviour itself should only notify one of the handlers(via NotifyHandler::Any) and thus no duplicate message will be sent through different connections(or transports).

[drHuangMHT]

If you want to customize the behaviour, the good news is, you can! And you will be able to remain compatible with the reference implementation, because no change will be made to the underlying protocol. You may keep a record of the connection handler ID and its corresponding transport type for future use.

[jsamol]

Now that you made me realized it, I did indeed find a bug in my code involving calling request_response::Behaviour::send_request with the same peer id more than once. I must have misinterpreted the logs and made incorrect assumptions 🙈

But I'm glad I asked the question after all, because what you said about the behaviour customization sounds really interesting! I'm guessing you're talking about a custom implementation of the NetworkBehaviour trait rather than relying on the derived default?

[drHuangMHT]

I'm guessing you're talking about a custom implementation of the NetworkBehaviour trait rather than relying on the derived default?

Well, I don't fully understand what you mean by "rather than relying on the derived default" because you will need the derive macro to combine multiple behaviours together. What I mean is, you can get a copy of libp2p-request-response and tinker with it, for example its NetworkBehaviour implementation, so that you can specify which outbound connection(interface) to use.
You can keep a map between interfaces and connection handler ids(e.g. HashMap<(Multiaddr,PeerId),ConnectionId>) by listening for SwarmEvent::ConnectionEstablished, and write a new implementation of send_request so that it accepts another Multiaddr as an argument to specify which interface to use. Though be warned that if the handler doesn't exist the failure is silent.

[drHuangMHT]

You can in theory write a custom implemetation of NetworkBehaviour for greater flexibility, but it will be hard. For example #5486 is trying to rewrite the derive macro but it is a pain.

[jsamol]

What I mean is, you can get a copy of libp2p-request-response and tinker with it

Ah, I see. I was wondering if the library's interface was already flexible enough to allow for this customization easily, but yes, adjusting the protocol's code is always an option, I guess.