Is it fine to have multiple RequestResponse fields in a single network behaviour struct?

[tqwewe]

Is the following network behaviour struct problematic given the two RequestResponse fields?

#[derive(NetworkBehaviour)]
struct Behaviour {
    foo: libp2p_request_response::cbor::Behaviour<FooReq, FooResp>,
    bar: libp2p_request_response::cbor::Behaviour<BarReq, BarResp>,
}

enum FooReq { }
enum FooResp { }
enum BarReq { }
enum BarResp { }

Will the request responses correctly work together without messages being mixed between them causing issues?

The reason I ask, is that from an ergonomic perspective, it drastically simplifies an API for my crate if its fine to do something like this.

[romac]

It should be fine as long as you construct each behavior with a unique StreamProtocol so that libp2p can associate a separate stream with each one.

[dariusc93]

Yes its fine to have multiple request response behaviour. Like @romac said, they would need to have their own unique protocols.

[tqwewe]

To extend my question, is it fine/possible to have multiple kademlia instances within a single NetworkBehaviour?

I'm building a wrapper around kademlia for a distributed actor registry, and it would be nice if I could keep the internal kademlia private without restricting users from adding their own kademlia DHT. I've done this with request_response, but I'm not sure if its also fine with kademlia, since I can't specify any kind of unique stream protocol.

[dariusc93]

Yes, but like previous answer, you would want to have each protocol with its own protocol (which you can do when you construct the Config for kad). You can do this with almost any behaviour BTW.

[tqwewe]

Oops i didn't see you could add a protocol to kademlia, that's so awesome thank you!