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 <[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
