[zeromq-dev] REQ to many REP.

Riskybiz riskybizlive at live.com
Tue Jun 24 19:30:11 CEST 2014


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/c3342960/attachment.htm>


More information about the zeromq-dev mailing list