Look into the DEALER/ROUTER combo, especially as described in the Paranoid Pirate pattern from the guide (http://zguide.zeromq.org/page:all#Robust-Reliable-Queuing-Paranoid-Pirate-Pattern).
You could probably do with just one ROUTER bound on the data collector, each data source connecting with a DEALER. Each source can send messages to the collector asynchronously, and the collector can route messages to specific sources. The async-ness also leaves you open to doing heartbeating on these existing channels. Sean On Tue, Jun 24, 2014 at 10:30 AM, Riskybiz <[email protected]> wrote: > I see in the 0MQ guide that it is possible to connect a single REQ socket to > many REP sockets. I also read that DEALER to REP is a valid pattern. I > have the impression that in both cases the sent messages would be > DISTRIBUTED among the connected REP sockets, in a manner which is desirable > for multithreading purposes but not necessarily for my scheme. I would need > to have a message originate from REQ or DEALER and have it directed to a > PARTICULAR REP socket of the several connected. Is this possible? > > > > I’m trying to cook up my own answer to a certain problem and am getting lost > in the options that 0MQ presents! In the event that someone may be able to > suggest a suitable 0MQ pattern to prevent me from reinventing the wheel I’ll > explain what I’m trying to do…… > > > > There will be several (flexible number) instances of time-series data source > applications; it is important that data arrives in the order in which it was > sent and nothing is lost/dropped enroute. > > > > Each time-series data source will control a REP socket and a PUSH socket. > > > > 0MQ message payloads will be custom boost::serialized object instances > carrying port addresses, commands and data payloads. > > > > There will be a single instance of a separate data-collecting application > which gathers all the data from all the sources. It will have a PULL socket > and a REQ socket. > > > > Every PUSH socket will start out sending serialized “Hello from PUSH port > ‘n’ ” messages. > > > > When the PULL socket receives one of these “Hellos” it will trigger a > message out of the REQ socket, back to the REP (address is specified in the > “Hello”) of the originating instance; that message will indicate the > connection is established and allow the data source to switch over from > “Hellos” and instead PUSH serialized data source payloads. > > > > The first data payload will be significant as it is the accumulated > time-series data history; subsequent data payloads will be smaller real time > updates. > > > > Some manner of heart beating / keep alive could / would be built in to this. > > > > Anyone have any suggestions on 0MQ patterns to implement this, perhaps a > variation of what I propose or something altogether better? > > > > Thanks, > > > > Riskybiz. > > > > > > > > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
