On Thu, Jul 28, 2016, at 06:44 PM, Johnathan Corgan wrote: > The ZMQ REQ/REP dataflow has the receiving end REQuest data from the > sending end when needed, which REPlies with a packet. It's a form of > flow control. > > From the GNU Radio perspective, streams flow into GNU Radio sinks to > exit the flowgraph, and data is sourced into a flowgraph from a GNU > Radio source block. > > Thus, the correct model is GR Stream | GR REP Sink | ZMQ REP | ZMQ > Transport | ZMQ REQ | GR REQ source | GR stream
The GR stream is no longer the "pull" model that it was back in the day. If anything, it's more the "push" model: data is created at sources and moved downstream, processed & moved again until it reaches sinks. It's just as valid to say that the sending end generates data, sends it via ZMQ, & REQuests a reply; the receiving end gets the data via ZMQ then REPlies; hence REQ/sink -> REP/source instead of the other way around. That's the model the ZMQ folks use in their Figure 2 from http://zguide.zeromq.org/page:all . I'm not saying it's the only way to do things; what I am saying is that in a quick internet search this REQ/sink -> REP/source is how some other projects do their transport. I can't review all projects, so I can't say "many" or "all"; I did not find any projects that didn't do it this way, except GNU Radio, though they do likely exist. My argument here is that it's equally valid to do the ZMQ REP/REQ transport either way, and if other projects are doing it the opposite way from GNU Radio, why aren't we providing an option to support that way? As I wrote: I'm just going to create my own OOT that swaps the REP/REQ names, so that it works with my project. - MLD
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
