[zeromq-dev] REQ to many REP.

Sean Robertson sprobertson at gmail.com
Wed Jun 25 02:23:23 CEST 2014


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 <riskybizlive at live.com> 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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list