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

[Michael Dickens]

Hi Andy - Thanks for your detailed thoughts on the subject matter.

I think we're all in general agreement that there are 2 ways to do REP /
REQ with respect to which is client and which is server. GR implements
one of those ways, but could easily provide the other, too. It's just
another way of looking at which is server and which is client. Neither
is more or less correct; they are just different implementations.

I'm looking for an OOT to do the REP /REQ way that GR does -not-
provide, or will just create one myself. I don't anticipate adding it to
the core gr-zeromq component. I agree that it would add unnecessary
complexity to those already-existing blocks. - MLD

> I think this would make the gr-zmq C++ block code unnecessarily complex
> and harder to maintain.  The block requirements for each combination of
> parameters grow in different directions.
> 
> Some things you'd have to deal with:
> 1. REP blocks have a receive then send main loop;
>    REQ blocks have a send then receive main loop.
> 
> 2.  REQ/REP can never drop messages/samples and so the tag propagation
> code can be simple;
>     PUB/SUB can drop messages/samples and tag propagation code needs to
> account for that in tag offsets
> 
> 3. GNURadio messages are usually small enough that they can be handled
> in one call to work().  GNURadio sample stream payloads can have a great
> many samples that need to be handled across several calls to work().