Close#636
The PR updates the send logic to use a select with ctx.Done() and
t.p.ctx.Done(), ensuring the operation terminates gracefully. A test
case reproducing the issue is included in the PR for verification.
topic.Publish is already thread safe. topic.AddToBatch should strive to
follow similar semantics.
Looking at how this would integrate with Prysm, they use separate
goroutines per message they'd like to batch.
See #610
We previously send IDONTWANT only when forwarding. This has us send
IDONTWANT on our initial publish as well. Helps in the case that one or
more peers may also publish the same thing at around the same time (see
#610 for a longer explanation) and prevents "boomerang" duplicates where
a peer sends you back the message you sent before you get a chance to
send it to them.
This also serves as a hint to a peer that you are about to send them a
certain message.
to support batch publishing messages
Replaces #602.
Batch publishing lets the system know there are multiple related
messages to be published so it can prioritize sending different messages
before sending copies of messages. For example, with the default API,
when you publish two messages A and B, under the hood A gets sent to D=8
peers first, before B gets sent out. With this MessageBatch api we can
now send one copy of A _and then_ one copy of B before sending multiple
copies.
When a node has bandwidth constraints relative to the messages it is
publishing this improves dissemination time.
For more context see this post:
https://ethresear.ch/t/improving-das-performance-with-gossipsub-batch-publishing/21713
* - added PublishWithSk functionality on the Topic implementation
* - fixes after merge
* - complete refactor: used publishing options instead of a new function
* - added one more check in unit test
* - bugfix: use local variables instead of fields
* - renamed tests
That is, when MinTopicSize is used but not WithDiscovery,
Publish will keep waiting until MinTopicSize's condition is met.
At the moment, this is done by polling every 200ms.
In the future, the mechanism could be optimized to be event-based.
A TODO is left for that purpose.
Fixes#454.
When the WithDiscovery option is passed to PubSub then PubSub will be able to search for more peers that are interested in our topics.
This includes the ability for Publishes (via Topic.Publish()) to block until the router is ready to publish. When a router is ready is currently defined by a combination of a user defined MinTopicSize function (passed into topic.Publish via the WithReadiness publish option) and the properties of the pubsub router used. The discovery tests show example usage.
Added PubSub.Join(topic) that returns a Topic object. This object can be Subscribed and Published to as well as to get a TopicEventHandler for topic events. This means that the Subscription object will no longer handle PeerEvents and that PubSub's Publish and Subscribe functions are deprecated.
