ZMQ_ROUTER_NOTIFY doesn't have a context and doesn't play nice with protocols. with ZMQ_DISCONNECT_MSG we can set it to a protocol message, like DISCONNECT in majordomo. Router will send it when a peer is disconnected. Another advantage of ZMQ_DISCONNECT_MSG is that it also works on inproc.
Together with ZMQ_HEARTBEAT it allows to build very reliable protocols, and much simpler as well.
When using ZMQ_HEARTBEAT one still needs to implement application-level heartbeat in order to know when to send a hello message.
For example, with the majordomo protocol, the worker needs to send a READY message when connecting to a broker. If the connection to the broker drops, and the heartbeat recognizes it the worker won't know about it and won't send the READY msg.
To solve that, the majordomo worker still has to implement heartbeat. With this new option, whenever the connection drops and reconnects the hello message will be sent, greatly simplify the majordomo protocol, as now READY and HEARTBEAT can be handled by zeromq.
Solution: a new socket type, called PEER. Very similar to SERVER, but can only connect to other PEERs. Also a new zmq_connect_peer method, that connect and return a routing-id in thread-safe and atomic operation
Solution: now if the first frame in a multipart message is not subscribe/unsubscribe,
the rest of the parts are also considered to be not subscribe/unsubscribe.
* Add ZMQ_XPUB_MANUAL_LAST_VALUE
* Surpport xpub send last value caching to one pipe with ZMQ_XPUB_MANUAL_LAST_VALUE
* Add test_xpubub_manual_last_value
* Add relicense and doc
Solution: Allow ZMQ_PUB and ZMQ_PUSH sockets types for the monitoring.
This way someone could create a ZMQ_PULL socket connected to multiple
monitoring sockets at the same time.
Solution: add API and ZMQ_EVENT_PIPES_STATS event which generates 2
values, one for the egress and one for the ingress pipes respectively.
Refactor the events code to be able to send multiple values.
Solution: revert DRAFT -> STABLE API transition so that we can do a
bugfix-only 4.2.5 release.
Will be re-reverted once tagged.
Revert "Problem: ZMQ_BINDTODEVICE has met STABLE conditions"
This reverts commit 3cb79f5042.
Revert "Problem: ZMQ_MSG_GSSAPI_* have met STABLE conditions"
This reverts commit 374da4207b.
Revert "Problem: ZMQ_MSG_T_SIZE has met STABLE conditions"
This reverts commit 6411c4a247.
Revert "Problem: docs say STABLE API still in DRAFT"
This reverts commit 9f2f30b7ff.
Solution: move it from DRAFT to STABLE since it's been in a public
release, committed for 6+ months and has not changed.
Given a new STABLE symbol has been added, bump minor version number.
Lets the application set per-connection metadata.
Metadata is specified as "X-key:value" and set using zmq_setsockopt, eg:
zmq_setsockopt (s, ZMQ_METADATA, "X-key:value", 11);
The peer can then obtain the metadata from a received message:
char *data = zmq_msg_gets(msg, "X-key");
The zero copy decoding strategy implemented for 4.2.0 can lead to a large
increase of main memory usage in some cases (I have seen one program go up to
40G from 10G after upgrading from 4.1.4). This commit adds a new option to
contexts, called ZMQ_ZERO_COPY_RECV, which allows one to switch to the old
decoding strategy.
* Background thread scheduling
- add ZMQ_THREAD_AFFINITY ctx option; set all thread scheduling options
from the context of the secondary thread instead of using the main
process thread context!
- change ZMQ_THREAD_PRIORITY to support setting NICE of the background
thread when using SCHED_OTHER
Solution: add ZMQ_ZAP_ENFORCE_DOMAIN to hide backward incompatible
change and make it disabled by default.
In a future release that breaks API compatibility we can then switch
the default to enabled in order to achieve full RFC compatibility.
Fixes#2762
