[zeromq-dev] REQ to many REP.

Panu Wetterstrand panu.j.m.suominen at gmail.com
Wed Jun 25 06:38:39 CEST 2014


Why the data is not simply queried using REQ socket? Why PULL-PUSH sockets are used to "establish connection"?

It would seem that simple "give me next data" query might be enough. But I read you explanation quite fast, so I might be wrong.

—
Sent from Mailbox

On Tue, Jun 24, 2014 at 8:30 PM, 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.
>  
>  
>  
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140624/0cd6a044/attachment.htm>


More information about the zeromq-dev mailing list