[zeromq-dev] Newbie Bait Request: Debug "Warning" mechanism.

Pieter Hintjens ph at imatix.com
Wed Aug 18 13:00:18 CEST 2010


On Wed, Aug 18, 2010 at 11:53 AM, Alexey Ermakov <zee at technocore.ru> wrote:

> I'm not sure if I agree with that. Pubsub seems to imply “start with
> nothing, then add/remove subscriptions” to me — I can't think of
> pubsub use cases where starting broad would be desired (rss/news
> distribution, email subscriptions, chats, market data all imply
> explicit subscriptions).

Traditional pubsub does indeed work this way but 0MQ pubsub sockets
are often (mostly?) used for simply broadcasting events within an
application.

For example: inproc://error publishing error events.  Natural use
case: get all errors, then refine to classes of errors.  Seems fairly
typical.

> But you've already got a socket type that performs unidirectional
> multicast on the publishing side and aggregation of data from multiple
> sources on the other — ZMQ_PUSH/ZMQ_PULL.

PUSH does load balancing, and PULL has no notion of filtering, and
using PULL to talk to a PUB would be disallowed.

Hmm... making a second socket type might be neatest after all, these
are two opposite ways to see and use pubsub.  How does something like
this feel:

socket = context.socket(zmq.SELECT)
socket.connect("inproc://error")
socket.setsockopt(zmq.WHERE, "fatal")
socket.setsockopt(zmq.WHERE, "debug")

vs.

socket = context.socket(zmq.SUB)
socket.connect(marketdatafeed)
...
socket.setsockopt(zmq.SUBSCRIBE, topic)
socket.setsockopt(zmq.UNSUBSCRIBE, topic)

-Pieter



More information about the zeromq-dev mailing list