Re: [Discuss-gnuradio] ZMQ REQ / REP naming Swap?

[Andy Walls]

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