[zeromq-dev] What are the “serious caveats

[Montero, Antonio UTC CCS]

Hi and apologize for the long mail in advanced,

Following up on the issue of PGM NAKs not being reacted to by PUB socket. You mention a few things about monitoring the PUB socket FD in order to trigger calling zmq_poll() on the SUB socket.
How is calling zmq_poll() on the SUB socket triggering PGM engine to process NAKs from clients which are in fact coming into the PUB socket?

I have been doing a lot searching on this topic and I am not able to discern the information as multiple posts contradict each other.
This is my situation:
I have both a PUB and a SUB socket being serviced in separate threads.
The PUB socket sends data at the request of the application/user but at least one packet is sent every 5 seconds.
The SUB socket sits in a loop calling zmq_recv() with a timeout ( timeout set via socket option ).  As long as data is coming in it will continue to call zmq_recv() until it times out at which point in goes and does something else and comes right back into the zmq_recv() call.

I have setup a test where I am causing packets sent by the PUB to be dropped somewhere in the network link and a remote SUB is sending the corresponding NAKs back to the PUB via unicast. I do not see the PUB replying with any NCF or RDATA.
Given that ZMQ does not support zmq_recv() call for PUB sockets, how is it that the engine is woken up to process those incoming NAKs?
I was under the impression that the PGM layer would automatically take care of processing incoming messages into a PUB socket. Based on your post it looks like any activity on either PUB or SUB sockets should wake this processing up however that is not what I am experiencing.
BTW: I am not doing any checking for: ZMQ_EVENTS on either socket since I am periodically calling them and I don’t do any polling on FD of either socket since I control the blocking on zmq send and receive calls via timeout socket options provided by ZMQ.

Any help/clarification would be greatly appreciated.

Antonio Montero.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180316/c88af0b9/attachment.htm>