-
Is the following network behaviour struct problematic given the two #[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. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 2 replies
-
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. |
Beta Was this translation helpful? Give feedback.
-
Yes its fine to have multiple request response behaviour. Like @romac said, they would need to have their own unique protocols. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
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.