Re: ZeroMQ Linger option

[Cameron Matson]

I think I came up with something that will work.  I'm trying to implement a carrier sense/collision avoidance scheme for wireless packet transmission.  Whenever the rx chain detects a packet,  it pushes it via zmq it to another process running a controller script which runs a state machine between "backoff", "listen", and "talk" states.  The problem I was having was that I was only handling zmq messages during the "listen" state and so if I had two USRPs trying to transmit messages, whichever went first would cause the other to backoff and then messages would build up in the the receivers queue (or whatever the buffered memory zmq uses).  I was thinking that if I could somehow programmatically close and reopen the socket only when I was in the listen state I could prevent this buildup.

I ended up changing the logic of the control program to continuously call the zmq poller and then handle the message only if the backoff time expired and it was attempting to transmit, which seems to be working for what I want

There's probably a cleaner and more semantic way of doing this.  I am by no means an expert at gnuradio or sockets, but I think what I have is good enough for now.

Thanks for your help,

Cameron

On Tue, Aug 11, 2020 at 5:32 AM Jeff Long <willcode4@gmail.com> wrote:

Not that I can see. What effect are you looking for, though?

On Mon, Aug 10, 2020 at 11:08 PM Cameron Matson <ncmatson95@gmail.com> wrote:

Ah, thanks for clearing that up.  And it looks like there's no way to manually close/reopen the socket that gets created by the flowgraph correct?

Cameron

On Mon, Aug 10, 2020 at 6:15 PM Jeff Long <willcode4@gmail.com> wrote:

Also, time is always set to 0 for the setsockopt ZMQ_LINGER call, which would cause immediate shutdown of the socket. This is not related to timeout, which is used as the polling timeout.

On Mon, Aug 10, 2020 at 7:06 PM Jeff Long <willcode4@gmail.com> wrote:

At socket shutdown, LINGER determines how long close(2) or shutdown(2) will block waiting for queue messages to be sent. See man socket(7).

On Mon, Aug 10, 2020 at 7:00 PM Cameron Matson <ncmatson95@gmail.com> wrote:

Hi all,

Can someone help me understand what's going on with any of the ZMQ Message Sink blocks?  The block takes a timeout parameter which is assigned to d_timeout, but ultimately it looks like the zmq.LINGER option (which I believe is how long zmq will block before dropping the frame) is always set to a different variable, time, which is initialized in the constructor to be 0 that is used for the setsockopt call.

if (major < 3) {
	d_timeout = timeout * 1000;
	}
	d_context = new zmq::context_t(1);
	d_socket = new zmq::socket_t(*d_context, ZMQ_REP);
	int time = 0;
	d_socket->setsockopt(ZMQ_LINGER, &time, sizeof(time));

Am I missing something?

Thanks,

Cameron