Hello, sorry for late reply.
I do not know why you are trying to publish something on a topic and after that enter in a blocking routine of waiting for a message (that might never come)
If you separate concerns: new messages get buffered in concurrent structure whenever they are fetched (from validator func or subscr.Next), a go routine acting as a worker monitors buffer structure for new data (that might also consume it) and this go routine might trigger publish whenever a new message needs to be sent to other peer.
What exactly are the requirements of your project?
Hi, thank you! My project is a blockchain project with two goroutines:
In the first goroutine, terminal inputs are handled: peers can create a message ( for example a new block proposal or a response to another proposal) and publish it to all other peers that are subscribed to a topic.
In the second goroutine, the other peers receive this message, check it (is it correct, is it for me, does it arrive double etc.), display it or process it (e.g. when the message contains special content).
The second goroutine is there to always be able to receive new messages and then handle them (also in your example code you use a go routine to receive messages). Depending on the message data (=content) different actions are performed. If nothing comes, nothing must be done apart from waiting.
–> do you think this goroutine is blocking the message flow?
Thank you for your help!!
It looks ok what you are trying to do. I thing it will work if you call in a go routine the publishing to pubsub as this is a blocking call that needs to write on a channel (from pubsub.go’s main loop). Also you will avoid deadlocks when dealing with reading/writing to pubsub.
Okay. You mean an additional goroutine for publishing within (!) the other two goroutines I mentioned before?
Currently I use mutex to avoid data races while publishing the messages:
mutex.Lock()
Subsription.Publish(topic, msg)
mutex.Unlock()
You can safely have something like:
go pubsub.Publish(topic, msg)
1 Like
Hey @samy27, just dropping in to point out that you seem to have a small misconception about streams (from what I read above). libp2p hosts are connected with normal (usually tcp) connections that go from one peer to other peer. Streams are multiplexed over that connection. Streams have protocol tags attached and that’s how they end up on one stream handler or another on the receiving end.
Unlike the connections, streams tend to be short-lived and purpose-specific: send some data, close stream. This is because it is much cheaper to open/close them than the underlying connections.
1 Like
Hi @hector, thank you for this clarification!