On Mar 26, 2012, at 10:24 AM, Rajalakshmi Iyer wrote: > Hello, > > I understand I have to use zmq_poll which is essentially event-driven. So > that solves problem (1) and (3). However, I still need some comments on point > (2) below. > > Thanks! > > On 26 March 2012 12:52, Rajalakshmi Iyer <r...@blismobile.com> wrote: > Hello, > > I am working on a requirement whereby a process (say producer) needs to send > out one-way messages to a variable number of processes (say consumers). > > The publish-subscribe model seemed good for this because the consumers will > subscribe to messages from the producer. I tried using ZeroMQ to achieve this. > > However, I have a few problems with it: > > The consumers have to continuously poll for messages. I would have the > consumers to be notified when there is a new message. > > There is a possibility of the producer queue being filled up. I would have > liked the producer to remove messages from the queue based on some condition > (say remove messages older than 5 seconds, or remove messages that have been > read 5 times). I see ZMQ recommends using a HWM, but I would like more > selective removal of elements from the buffer. > > Since the consumers are polling and the messages are not removed from the > queue, the consumers see duplicate messages till a new message comes in. I > want the consumer to be notified only once per new message. > > I understand I may be using a wrong model (publish-subscribe may not be > suitable). I have thought about using request-reply, but that doesn't work > since the producer does not want to keep track of the number of consumers. > > Can anyone suggest a good alternative? >
Raj, I recommend that you read this posting: http://unprotocols.org/blog:15 That is a far better mechanism than the built-in HWM mechanism. Since it isn't built in to the library, you would have to add this logic at the application level. Since it *requires* two-way communication between the client and server, you cannot use the PUB/SUB sockets. You would need to use DEALER/ROUTER sockets to handle this communication. Yes, this will be a little more work but it is necessary for the kind of flexibility that your #2 issue requires. I hope this helps. cr PS - we would *love* it if someone made a patch to libzmq that added credit-based flow control as an option for all socket types.
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
