On Fri, Dec 30, 2011 at 3:36 PM, Joshua Foster <[email protected]> wrote:
> After playing around with the XPUB/XSUB/PUB/SUB, I found that it won't > work. XPUB only receives messages when a brand new subscription is received > or the all the subscribers unsubscribe. For example: > > sub.subscribe([2, 2, 3, 5) > xsub.send([1, 2, 2, 3, 5], 0) > > xpub.recv(0) // this is [1, 2, 2, 3, 5] > xpub.recv(0) // this will block because it is the same subscription > > Joshua > In general the PUB/SUB structure is designed for a stream of data with a variety of subscribers. If you look in the guide there are a few advanced pub sub patterns, but in general if you provide a req-rep service that can get a set of updates by request, you can have joiners subscribe when they connect, and once they receive a message request any old ones via that req rep. If you don't actually want to start sending data until you have subscribers then you can use a subscribe signal as described or via req/rep as you mentioned. You can do the same thing via pub/sub, so if you have your 'publisher' of the data be a 'subscriber' to a sync channel, you can push a sync message out of one client side to as many subscription channels as you need - this would be much cleaner than your req to multiples reps. If you really don't want to actually send until you have *all* your subscribers, then you might want to consider whether you might be better served by a req/rep based pattern - the point of pub sub is that you don't really know how many subscribers you have. The issues occur once you start thinking about what happens if a new subscriber is added, or an existing one removed - you have to signal that through whatever mechanisms, which effectively couples the components of your topology together. Ian
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
