Fixes not receiving unsubscription messages in XPUB socket with
ZMQ_XPUB_VERBOSE and using a XSUB-XPUB proxy in front.
This adds two modifications:
- It adds a new flag, ZMQ_XPUB_VERBOSE_UNSUBSCRIBE, to enable verbose
unsubscription messages, necessary when using a XSUB/XPUB proxy.
- It adds a boolean switch to zmq::mtrie_t::rm () to control if the
callback is invoked every time or only in the last removal. Necessary
when a pipe is terminated and the verbose mode for unsubscriptions is
enabled.
Set the ZMQ_HEARTBEAT_TIMEOUT to default to the value of
ZMQ_HEARTBEAT_IVL if it's not explicitly set.
Change the units of ZMQ_HEARTBEAT_TTL to milliseconds in the API
and round down to the nearest decisecond so that all the options
are using the same units.
Make the maximum heartbeat TTL match the spec (6553 seconds)
Pull request #1426 now allow for changing the watermark
after and connect() or a bind(). This patch reflect the
change in the documentation.
Also closes#1416.
zmq_term and zmq_ctx_destroy are just aliases for zmq_ctx_term. that
being the case use 'terminate' in the description for all three so there
isn't any confusion about behavior.
also update the deprecates list in zmq_ctx_term to include
zmq_ctx_destroy.
ZMQ_INVERT_MATCHING reverses the PUB/SUB prefix matching. The subscription
list becomes a rejection list. The PUB socket sends messages to all
connected (X)SUB sockets that do not have any matching subscription.
Whenever the option is used on a PUB/XPUB socket, any connecting SUB
sockets must also set it or they will reject everything the publisher
sends them. XSUB sockets are unaffected because they do not filter out
incoming messages.
Symptom is that ZMQ_STREAM sockets in 4.1.0 and 4.1.1 generate zero
sized messages on each new connection, unlike 4.0.x which did not do
this.
Person who made this commit also changed test cases so that contract
breakage did not show. Same person was later banned for persistently
poor form in CZMQ contributions.
Solution: enable connect notifications on ZMQ_STREAM sockets using a
new ZMQ_STREAM_NOTIFY setting. By default, socket does not deliver
notifications, and behaves as in 4.0.x.
Fixes#1316
Allows non-C/C++ based clients easy access to the peer's IP address via
zmq_msg_gets(&msg, "Peer-Address") instead of zmq_msg_get(&msg, ZMQ_SRCFD)
followed by calls to getpeername and getnameinfo
zmq_atomic_counter_dec returned a 'bool' value, yet this isn't
defined by standard, so causes compile errors in upstream code.
Solution: return an int that can be safely converted to bool if
needed by bindings.
Solution: as libzmq already provides this across all platforms,
expose an atomic counter API. I've not wrapped atomic pointers,
though someone who needs this may want to do so.
Solution: set defaults back to infinity, and add new context
option, ZMQ_BLOCKY that the user can set to false to get a
less surprising behavior on context termination. Eg.
zmq_ctx_set (ctx, ZMQ_BLOCKY, false);
Solution: document this with a clear warning. It would be
nicer perhaps to change the default LINGER to e.g. a few
seconds. However this could break existing applications.
This commit adds a ZMQ_POLLPRI flag that maps to poll()'s POLLPRI
flag.
This flags does nothing for OMQ sockets. It's only useful for raw
file descriptor (be it socket or file).
This flag does nothing if poll() is not the underlying polling
function. So it is Linux only.
Solution: document the limit of 113 chars including ipc://. We might
fix this in libzmq by shortening an over-long IPC pathname into a
unique string; so long as this is done consistently in bind and in
connect, it will save applications from weird failures when they
use external data to generate IPC pathnames.
Solution: change setsockopts on printable keys to expect 41, nor 40
bytes. Code still accepts 40 bytes for compatibility, and copies the
key to a well-terminated string before using it.
Fixes#1148
