From: Michael Dickens Date: Thu, 28 Jul 2016 20:23:36 -0400 > 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
[snip] >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? [snip] The ZMQ Guide is pretty clear that the core REQ/REP pattern is intended to have the following usage: REQuests are sent by Clients REPlies are sent by Servers Likewise in GNURadio it is clear that Sinks send data out of a GNURadio instance Sources send data into a GNURadio instance Server vs. client and Source vs. Sink are orthogonal. So any of the following is valid: REQ source REQ sink REP source REP sink REQ msg source REQ msg sink REP msg source REP msg sink But what you actually should use depends on the functional context. In the context of using REQ/REP, here are some use cases where I would likely use a GNURadio instance as a server or a client. This is for GNURadio instances communicating with programs which are not GNURadio instances: GNURadio as a client: --------------------- (C1) Accepting medium to high rate sample data from an external source for RX processing (REQ source) (C2) After Rx processing, providing medium to low rate PDUs/messages to an external source. (REQ msg sink) (C3) Providing low rate status messages (REQ msg sink) (C4) Accepting low rate sample data from an external source for further Tx processing (REQ source) GNURadio as a server: --------------------- (S1) Tx processing output providing medium to high sample rate data to an external source (REP sink) (S2) Accepting medium to low rate PDUs/messages for Tx processing (REP msg source) (S3) Accepting low rate command and control messages (REP msg source) (S4) After some Rx processing providing low rate sample data to an external source (REP sink) Of course other developers can have other design preferences than those above. In the above, I would actually never use REQ/REP for cases C1 and S1. REQ/REP is too high overhead and provides a reliability guarantee way beyond what is the norm for SDR. (libuhd/USRP source will drop data on the floor if your GNURadio instance can't keep up; REQ/REP will not.) REQ/REP is not the right pattern to use for high rate data. From the ZeroMQ Guide: "Request-reply, which connects a set of clients to a set of services. This is a remote procedure call and task distribution pattern." TL;DR: REQ is for clients, REP is for servers. ZeroMQ REP/REQ is orthogonal to GNURadio source/sink. Some (REQ/REP, stream/msg, source/sink) block functional combinations are missing from gr-zmq. The current gr-zmq REQ/REP source/sink block combinations are not wrong or incorrect, but they might not fit the usage pattern one may need or envision in a particular context. Don't use REQ/REP for medium to high sample rate sample streams. Regards, Andy _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio