This allows clients and workers to directly communicate data between each other with a typical Publish-Subscribe pattern. This involves two components,

Pub objects, into which we put data:

>>> pub = Pub('my-topic')
>>> pub.put(123)

And Sub objects, from which we collect data:

>>> sub = Sub('my-topic')
>>> sub.get()
123

Many Pub and Sub objects can exist for the same topic. All data sent from any Pub will be sent to all Sub objects on that topic that are currently connected. Pub's and Sub's find each other using the scheduler, but they communicate directly with each other without coordination from the scheduler.

Pubs and Subs use the central scheduler to find each other, but not to mediate the communication. This means that there is very little additional latency or overhead, and they are appropriate for very frequent data transfers. For context, most data transfer first checks with the scheduler to find which workers should participate, and then does direct worker-to-worker transfers. This checking in with the scheduler provides some stability guarantees, but also adds in a few extra network hops. PubSub doesn't do this, and so is faster, but also can easily drop messages if Pubs or Subs disappear without notice.

When using a Pub or Sub from a Client all communications will be routed through the scheduler. This can cause some performance degradation. Pubs and Subs only operate at top-speed when they are both on workers.

Parameters

name: object (msgpack serializable) :

The name of the group of Pubs and Subs on which to participate.

worker: Worker (optional) :

The worker to be used for publishing data. Defaults to the value of `get_worker()` . If given, client must be None .

client: Client (optional) :

Client used for communication with the scheduler. Defaults to the value of get_client() . If given, worker must be None .

Publish data with Publish-Subscribe pattern

See Also

Sub

Examples

This example is valid syntax, but we were not able to check execution

>>> pub = Pub('my-topic')
... sub = Sub('my-topic')
... pub.put([1, 2, 3])
... sub.get()
[1, 2, 3]

You can also use sub within a for loop:

This example is valid syntax, but we were not able to check execution

>>> for msg in sub:  # doctest: +SKIP
...     print(msg)

or an async for loop

This example does not not appear to be valid Python Syntax

>>> async for msg in sub:  # doctest: +SKIP
...     print(msg)

Similarly the .get method will return an awaitable if used by an async client or within the IOLoop thread of a worker

This example does not not appear to be valid Python Syntax

>>> await sub.get()  # doctest: +SKIP

You can see the set of connected worker subscribers by looking at the .subscribers attribute:

This example is valid syntax, but we were not able to check execution

>>> pub.subscribers
{'tcp://...': {},
 'tcp://...': {}}

See :

Back References

The following pages refer to to this document either explicitly or contain code examples using this.

distributed.pubsub.Sub distributed.pubsub.Pub

Local connectivity graph

Hover to see nodes names; edges to Self not shown, Caped at 50 nodes.

Using a canvas is more power efficient and can get hundred of nodes ; but does not allow hyperlinks; , arrows or text (beyond on hover)

SVG is more flexible but power hungry; and does not scale well to 50 + nodes.

All aboves nodes referred to, (or are referred from) current nodes; Edges from Self to other have been omitted (or all nodes would be connected to the central node "self" which is not useful). Nodes are colored by the library they belong to, and scaled with the number of references pointing them

---

File: /distributed/pubsub.py#202
type: <class 'type'>
Commit: