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

Hi Michael. Code isn't published, because it belongs to a project for the company I work for. But it was all in python and just for the combinations I needed... so you are probably not missing anything. :) Sorry. 2016-07-29 9:08 GMT-03:00 Michael Dickens : > Hi

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

On Fri, 2016-07-29 at 11:49 -0400, Michael Dickens wrote: > 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

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

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

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

> From: > Francisco Albani > Subject: > Re: [Discuss-gnuradio] ZMQ REQ / > REP naming Swap? > Date: > Thu, 28 Ju

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

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

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

Hi Francisco - Yes, I think having a generic ZMQ block would be awesome. Do you have an OOT module or block that does what you listed: a generic ZMQ block? If so, how do I gain access to it? This would save me lots of time! Thanks! - MLD On Thu, Jul 28, 2016, at 10:21 PM, Francisco Albani wrote:

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

Michael, I found the need to do the same for some applications. I also needed to choose between bind and connect (I made this a parameter of my block). Wouldn't be better to have just one sink and one source with selectable options, like: * socket_type: REP/REQ/SUB/PUB/PUSH/PULL * method: bind /

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

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

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

On Thu, Jul 28, 2016 at 12:20 PM, Michael Dickens wrote: > OK. I think the issue is that's not how ZMQ is designed to work with > respect to REQ/REP. I think it's designed to do "sink -> REQ -> ZMQ -> > REP -> source", so that the REQ is a sink & REP is a source. In

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

On Thu, Jul 28, 2016, at 03:11 PM, Sylvain Munaut wrote: > > But this model doesn't work for the REP / REQ in Figure 2 > > "Request-Reply". I would expect the ZMQ REQ to be a GR sink but instead > > if is a source; likewise, I'd expect the ZMQ REP to be a GR source & it > > is instead a sink. > >

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

> But this model doesn't work for the REP / REQ in Figure 2 > "Request-Reply". I would expect the ZMQ REQ to be a GR sink but instead > if is a source; likewise, I'd expect the ZMQ REP to be a GR source & it > is instead a sink. > > The internal coding is consistent with the external naming; I

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

I'm trying to work with the ZQM REQ / REP message blocks while learning about ZMQ. From their overview guide < http://zguide.zeromq.org/page:all >, they define various graphs where the interconnects are the ZMQ connections. Thus, for example, in Figure 4 "Publish-Subscribe", the PUB would be GR