Subscribe to PubSub topic before Publishing #30
Conversation
For IPNS, at least, we assume a single writer. However, I can't see this causing any issues. |
pubsub.go
Outdated
| @@ -94,6 +94,10 @@ func (p *PubsubValueStore) PutValue(ctx context.Context, key string, value []byt | |||
| p.mx.Unlock() | |||
| } | |||
|
|
|||
There was a problem hiding this comment.
We should remove the above bootstrapping lines if we're going to do it this way.
There was a problem hiding this comment.
@Stebalien done. #28 is also now glaringly obvious now, since we see that the context passed in is just ignored.
If you think it makes sense I could wrap the insides of this function (Subscribe + Publish) in a gofunc + channel wait wrapper, but I'm inclined to just leave that until we implement the Discovery in PubSub, per #28 .
There was a problem hiding this comment.
I'd leave it as-is. Subscribe shouldn't block anyways.
This PR adds a PubSub
Subscribeinto thePutValuefunction before calling PubSub'sPublish.The reason is that the PubSubValueStore is a persistent single writer data store as indicated by its use of a cache for
GetValueand its use of theisBetterfunction to determine what value to return. Were this node toPuta value that was not "better" than the value already on the network that would likely be a mistake. As a result it shouldSubscribeso that it has the current "best" value and can compare with that before sending out PubSub requests.While there are scenarios in which the extra inbound messages could be deemed "not worth it" to the
Publisher, I think you would be hard pressed to find them in this particular scenario. This is even more evident when noting that this router is mostly used by IPNS which plans to use the LWW PubSub implementation under development at libp2p/go-libp2p-pubsub#171.@vyzo @raulk How does this sound to you?