Hi Gonzalo, > I apologize in advance for the soup letter. Please bear with me for just > three short paragraphs. > > Say I have one process A, from which I wish to notify about certain > events by using Pub/Sub sockets, so that I can decouple the notifier > from the receivers of those notifications. A would generate events E, F > and G. > > On the receiver side, say I have processes P and Q; P is interested in > events E and F, Q is interested in events F and G. I could have process > A open three Pub sockets, for events E, F and G; then from P I would > open Sub sockets E and F, and from Q I would open Sub sockets F and G. > Presto! A can just go ahead and send out notifications, without worrying > if there are 1, 2 or 10 processes listening to them. > > Now, let's say I want to add a new process B, which generates events F, > G and H. So for the case of event F, I now have two processes (A and B) > generating the same event, and two processes (P and Q) interested in > that event. How would I do this? Although P and Q can open the same Sub > socket for event F, I don't think it would be possible for both A and B > to open the same Pub socket for that event. Or am I wrong? > > The only way I can think of implementing this pattern would be to have > one intermediate process N which acts as the central notifier. A and B > send all events to N (using Downstream sockets), which is now the ONLY > process opening Pub sockets and sending out notifications. This would > work, and it may even be "right"; the only concern would be that I now > centralize all notifications in a single point of failure.
Yes. You are right. If there are multiple senders and multiple receivers you have to have a forwarder process in the middle otherwise you would have to manually setup all the connections between senders and receivers. Et voila! There's such a process implemented in 0MQ already! Have a look at zmq_forwarder(7). For the example of code have a look at chatroom example: http://github.com/sustrik/zeromq-chat (check README file for detailed instructions) A side note: You may want to have "event types" managed automatically, guarantee the ordering etc. In such a case use a single PUB socket and tag the events by event type. For instance, message containing event of type A may look something like this: A|my-event-specific-data On the SUB side you can subscribe for a particular message types: zmq_setsockopt (s, ZMQ_SUBSCRIBE, "A|", 2); zmq_setsockopt (s, ZMQ_SUBSCRIBE, "B|", 2); etc. HTH Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
