Support REQ-REP protocol in 'SocketNotifierZMQSocket' implementation
Closed this issue · 6 comments
Sorry if this is the wrong place for a question. How might a person send a REQ and then block for the REP instead of handling it async later on? Is there some way to run the event loop as a sort of priority queue where the REP floats to the top? (I wouldn't want to service any other event while I am waiting for the REP.)
I'm afraid you need to handle this situation yourself. For example, by letting the client ignore all events until it received a REP.
But please send me notifications directly because, indeed, this issue is not directly related to your question.
!!! Disregard this. I was using zeromq-3.2-0-rc1(mac) and 3.2.1-rc2(linux). Upgrading both to 3.2.1-rc2 makes REQ-REP work fine in my example. Although the nzmqt REQ-REP example only works for about 2 message exchanges and then stops. Hmm.
Have you looked into this any further? I've noticed high CPU usage with PollingZMQContext on Linux (but not OS X) so I tried out the SocketNotifier version instead. It seemed to solve the CPU problem, but it only half works for REQ-REP.
My setup is OS X 10.8.2 and VirtualBox running Vagrant's Ubuntu 10.04 image.
Here's the weird part:
If I start the REP side on Mac and the REQ on Linux, it works fine.
But, if it's reversed (Mac is REQ, Linux is REP), I see that Linux receives one packet and sends a reply and the Mac gets a notification that the socket is ready for reading, but events() does not report any waiting messages. So it just stops there.
I think that SocketNotifier will not be reliable because data ready on the socket does not always align with data ready coming off the zeromq internal queue. I am not aware of a proactor or reactor that can work with memory queues, so polling is the fallback. The author can correct me if I'm wrong, but I think the best we can hope for is to increase the polling inverval to control CPU usage, while perhaps ALSO being notified via SocketNotifier in case this shaves off some latency in some cases where the data ready conditions happen to align. I.e., a merger of Polling and Notifier Contexts.
Anyone found a solution for this? QSocketNotifier seems to work reliable for PUB-SUB at least.
The polling implementation could be improved by using a blocking poll call in a separate thread. The Qt event dispatcher is able to pass events between different threads using the Qt::QueuedConnection.