gonzalo diethelm wrote: >> 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. > > Ok. Any thoughts about this forwarder being a single point of failure?
It's a tradeoff. Either you have centralised connection management and SPoF or you have to manage connection by hand. If you want to avoid the SPoF you can use hot-hot failover, i.e. stream messages through 2 instances of zmq_forwarder and discard the duplicates on the recevier side. > >> 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); > > Perfect, this was my plan to begin with. Quick question: does it matter > if the payload after the event tag contains binary characters? I am > using Google Protocol Buffers to marshal my data, so the payload could > contain anything, but I will have a fixed-length printable event tag > (such as your "A|", "B|", etc) prepended to the payload. Will it work, > in the sense that 0MQ will match only on those first N printable bytes > at the beginning? No, it doesn't matter. The message is opaque binary BLOB and the subscription is a binary BLOB as well. You'll get the message as long as the subscription BLOB is found at the beginning of the message BLOB. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
