It seems like we’re missing a lot of context here, which makes it difficult to answer your questions.
Right now I’m using Gossipsub with different channels to simulate my custom protocol, but I guess I should build my own protocol.
Could you elaborate on this a bit more? What do you mean by “simulate”? Are you ultimately planning to replace Gossipsub with a custom overlay topology / broadcast protocol? Assuming that is indeed the case, can you explain the significance of the different “channels” (do you mean “topics”?), and explain which part of your as-of-yet-unimplemented protocol they simulate?
This will help ensure our recommendations are in line with your actual goals … I’d hate for us to send you off in the wrong direction!
With my custom protocol I have to set autodial to false and managing all peer and stream management by the protocol.
What is your protocol designed to do? It seems like you wish to replace Gossipsub with another protocol that has (roughly) the same semantics as Gossipsub: namely, pubish-subscribe. In other words, it seems like you want to publish messages to topics, but you want these messages to be distributed to peers in a manner different than what Gossipsub does.
If this is indeed the case, your best bet would be to implement your own
PubSubRouter and pass it to
NewPubSub. This will give you a
PubSub instance that uses your own routing protocol – and manages its own connections – underneath.
Regarding autodial, this rings a bell but I couldn’t find it in the docs … can you point me to it? I suspect it’s somewhat orthogonal to your query because libp2p’s pubsub system does it’s own connection management internally.
While I have two type of peers in my protocol, with the useful protobuffer message in my custom protocol have any kind of self routing or I have to manage like gossippub?
I’m not sure I understand the question. Could you try reformulating it?
I hope this helps! If not, I’m happy to try again!