[zeromq-dev] a pub with multiple subs starting sequentially

Peter Fagerlund zmq at iprobot.com
Mon Nov 1 09:18:57 CET 2010

Maybe you could write a store que Device where you would store messages for
the time required for your problem domain ....

so you then have :

    pub => DeviceStore <= subs

On Mon, Nov 1, 2010 at 9:05 AM, Shaofeng Yang <syang at catchif.com> wrote:

> That's for one sub. Can it work with multiple subs? For example, sub1
> with its IDENTITY connects to the pub and later sub2 with its identity
> connects to the pub. then sub2 gets disconnected and then the pub
> starts to publish data, which will be received by sub1. some time
> later, sub2 re-connects to the pub. Can sub2 still receive the data
> received by sub1? Actually this is my original question since my
> program was written like this.
> Thanks,
> James
> On Mon, Nov 1, 2010 at 3:49 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:
> > On 11/01/2010 08:46 AM, Shaofeng Yang wrote:
> >>
> >> Thanks for your quick response, Martin. Do you think it might make it
> >> work once zmq moves to publisher side filtering. in this case, the sub
> >> can register itself first and then gets disconnected. it will receive
> >> the lost messages when it re-connects to the pub later. of course, it
> >> will have limited queue size/time out for the subs.
> >> or what's the best model/implementation for this case.
> >>
> >
> > You can do it even now. Set the identity (ZMQ_IDENTITY) on the subscriber
> > socket, then connect to the publisher. Given that the subscriber socket
> has
> > name, publisher is able to say that a new connection being made is
> actually
> > a reconnection and send it all the pending data. You'll never get
> messages
> > that were sent before you connected for the first time though.
> >
> > Martin
> >
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101101/3fe986d7/attachment.htm>

More information about the zeromq-dev mailing list