Hey, I had a comparable idea for shutting down.
BUT: a shutdown
command in a system that stops and respawns during normal runtime is
never ever something that can be treated as a typical
bcast/fire-and-forget and so should never be able to reach some worker
that is not meant to get it.
Such
Dear all,
I am new to zeromq. I have a question about message
queuing broker (msgqueue.c) which use zmq_proxy() forward msgs between
frontend and backend.
In my testing code, the mobile client is using ZMQ_DEALER
socket to connect to this broker. But after some time, I found
Instead of routing all information through the broker and requiring an
intermediary hop, I'd like to consider an approach where the address
information that the req socket parses out on the side that first sends
ready is used in order to manage a simple mutual connection facilitator in
ZMQ...
Just
Thanks for reviewing it. I'd not updated the patch number yet, have
done that now.
zmq_event_t is indeed gone, commit
9753de8566d335703c96160aa4e5f9c6e55208a9. The structure didn't
actually match monitor events.
On Sun, Jan 11, 2015 at 7:12 PM, Bob Clarke wrote:
> I pulled down the 0MQ 4.1.1 fil
I pulled down the 0MQ 4.1.1 files and noticed a couple things in the
contents of zmq.h:
1) ZMQ_VERSION_PATCH is shown as 0 instead of 1;
2) the zmq_event_t struct has been removed
Are these oversights, or is that the direction the code is going? If the
zmq_event_t struct is going away, then zmq
