Solution: add a preprocessor variable ZMQ_NO_EXPORT that, when set, bypasses the automatic ZMQ_EXPORT determination block and just sets ZMQ_EXPORT to empty.
By combining this solution at configuration time with manually passing -fvisibility=hidden to CXXFLAGS, I solved my visibility problem. Just passing -fvisibility=hidden is not enough, because __attribute__ ((visibility ("default"))) has higher priority.
zmq_ppoll mostly mimics zmq_poll behavior, except for the added feature of being able to specify a signal mask. Signals in this mask will be blocked during execution of zmq_ppoll. Switching of the process' active signal mask happens atomically with the actual poll call, so that no race conditions can occur. This behavior is useful when one wants to gracefully handle POSIX signals without race conditions. See e.g. the discussion below https://250bpm.com/blog:12/ for an explanation.
Also includes two new tests:
1. test_zmq_ppoll_fd does the same thing as test_zmq_poll_fd, demonstrating backwards compatibility with zmq_poll when used with a default signal mask.
2. test_zmq_ppoll_signals demonstrates the use of zmq_ppoll with a signal mask, blocking out SIGTERM everywhere except in zmq_ppoll, allowing to handle the signal in one place without having to worry about race conditions.
This is important in order to send the login sequence of a client to the server.
Solution: add ZMQ_HICCUP_MSG to a socket, socket would send that message whenever a connection get temporarly disconnected
* Problem: No direct support for setting socket priority
Solution: Add ZMQ_PRIORITY socket option, which sets the
SO_PRIORITY socket option on the underlying socket. This
socket option is not supported under Windows. Check option
and set socket option on creation of underlying socket.
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.
how it declares the file descriptor (fd) of a socket
in struct zmq_pollitem_t vs. struct zmq_poller_event_t
Solution: Make include/zmq.h consistent in this matter
* 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: define uint64_t if not available in the system headers and
remove inclusion of inttypes.h which does not exist and is already
conditionally included in zmq.h if required, do not use PRIx64
Solution: revert the revert!
Revert "Problem: regression in 4.2.3 went unnoticed, want to release 4.2.5"
This reverts commit 5f17e26fa4c60c3de0282d1b6ad1e8b7037ed57a.
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 3cb79f5042cf32cdb7b1b58d4acf17eba85ec9f7.
Revert "Problem: ZMQ_MSG_GSSAPI_* have met STABLE conditions"
This reverts commit 374da4207b8034b0fcd67a2cc2165d50e09b9387.
Revert "Problem: ZMQ_MSG_T_SIZE has met STABLE conditions"
This reverts commit 6411c4a247c08ead50919d16b30eb030eaf44a7e.
Revert "Problem: docs say STABLE API still in DRAFT"
This reverts commit 9f2f30b7ffa09acc51d3b87251a47e83b435d5d4.
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
* Fixing #2002 one way of doing it
* Mechanisms can implement a new method `error_detail()`
* This error detail have three values for the moment: no_detail
(default), protocol, encryption.
+ generic enough to make sense for all mechanisms.
- low granularity level on information.
* Fixing #2002: implementation of the error details
The ZMQ_EVENT_HANDSHAKE_FAILED event carries the error details
as value.
* Removed Microsoft extenstion for enum member access
This was leading to compilation error under linux.
* Adaptation of CURVE test cases
* Monitoring event: changed API for detailed events
Removed ZMQ_EVENT_HANDSHAKE_FAILED and replaced it by:
- ZMQ_EVENT_HANDSHAKE_FAILED_NO_DETAIL,
- ZMQ_EVENT_HANDSHAKE_FAILED_PROTOCOL,
- ZMQ_EVENT_HANDSHAKE_FAILED_ENCRYPTION
Adaptation of text case `security_curve`
* Removed event value comparison
This was introduced for the previous API model adaptation
* Removed the prints in std output and added missing details
`current_error_detail` was not set in every protocol error cases
* Fixed initialization of current_error_detail
* Fixed error in greeting test case
The handshake failure due to mechanism mismatch in greeting is actually
a protocol error. The error handling method consider it like so and
send a protocol handshake failure monitoring event instead of no_detail.
Fixed the test_security_curve expectation as well.
* Upgraded tests of monitoring events
The tests check the number of monitoring events received
* Problem: does not build under Linux or without ZMQ_DRAFT_API
Solution:
- properly use ZMQ_DRAFT_API conditional compilation
- use receive timeouts instead of Sleep
* Problem: duplicate definition of variable 'timeout'
Solution: merged definitions
* Problem: inconsistent timing dependencies
Solution: reduce timing dependency by using timeouts at more places
* Problem: assertion failure under Linux due to unexpected monitor event
Solution: output event type to aid debugging
* Problem: erroneous assertion code
* Problem: assertion failure with a garbage server key due to an extra third event
Solution: changed assertion to expect three events (needs to be checked)
* Problem: extra include directive to non-existent file
Solution: removed include directive
* Problem: assertion failure on appveyor for unknown reason
Solution: improve debug output
* Problem: no build with libsodium and draft api
Solution: add build configurations with libsodium and draft api
* Problem: assertion failure on CI
Solution: change assertion to reflect actual behaviour on CI (at least temporarily)
* Problem: error in condition in assertion code
* Problem: assertion failure on CI
Solution: generalize assertion to match behavior on CI
* Problem: assertion failures on CI
Solution: removed inconsistent assertion on no monitor events before flushing
improved debuggability by converting function into macro
* Problem: diverging test code for three analogous test cases with garbage key
Solution: extract common code into function
* Problem: does not build without ZMQ_BUILD_DRAFT_API
Solution: introduce dummy variable
* Attempt to remove workaround regarding ZMQ_EVENT_HANDSHAKE_FAILED_NO_DETAIL again
* Problem: EAGAIN error after handshake complete if there is no more data in inbuffer
Solution: Skip tcp_read attempt in that case
* Problem: handshaking event emitted after handshaking failed
Solution: use stream_engine_t::handshaking instead of mechanism_t::status() to determine whether still handshaking
* Include error code in debug output
* Improve debugging output: output flushed events
* Split up ZMQ_EVENT_HANDSHAKE_FAILED_PROTOCOL into ZMQ_EVENT_HANDSHAKE_FAILED_ZMTP and ZMQ_EVENT_HANDSHAKE_FAILED_ZAP
* Fixed compilation without ZMQ_BUILD_DRAFT_API
* Renamed ZMQ_EVENT_HANDSHAKE_SUCCEED to ZMQ_EVENT_HANDSHAKE_SUCCEEDED for language consistency
* Renamed ZMQ_EVENT_HANDSHAKE_SUCCEED to ZMQ_EVENT_HANDSHAKE_SUCCEEDED for language consistency
* Renamed ZMQ_EVENT_HANDSHAKE_SUCCEED to ZMQ_EVENT_HANDSHAKE_SUCCEEDED for language consistency
* Fixed assert_monitor_event (require event instead of allowing no event)
Reverted erroneous change to handshaking condition
Renamed test_wrong_key to test_garbage_key
Generalized assumption in test_garbage_key to allow for ZMQ_EVENT_HANDSHAKE_FAILED_NO_DETAIL with error == EPIPE
* Better isolate test cases from each other by providing a fresh context & server for each
* Added diagnostic output
* Changed assertion to reflect actual behavior on CI
* Fixed formatting, observe maximum line length
* Fixed formatting, observe maximum line length
* Increase timeout to check if this fixes valgrind run
* Close server with close_zero_linger
* Increase timeout to check if this fixes valgrind run
* Increase timeout to check if this fixes valgrind run
* Generalize assertion to also work with valgrind
* Fixed formatting
* Add more diagnostic output
* Generalize assertion to also work with valgrind
Linux now supports Virtual Routing and Forwarding (VRF) as per:
https://www.kernel.org/doc/Documentation/networking/vrf.txt
In order for an application to bind or connect to a socket with an
address in a VRF, they need to first bind the socket to the VRF device:
setsockopt(sd, SOL_SOCKET, SO_BINDTODEVICE, dev, strlen(dev)+1);
Note "dev" is the VRF device, eg. VRF "blue", rather than an interface
enslaved to the VRF.
Add a new socket option, ZMQ_BINDTODEVICE, to bind a socket to a device.
In general, if a socket is bound to a device, eg. an interface, only
packets received from that particular device are processed by the socket.
If device is a VRF device, then subsequent binds/connects to that socket
use addresses in the VRF routing table.
Problem: GSSAPI NAMETYPE socket option numbers were modified
+1000 when moved to DRAFT section, but should use the definitive
values while in DRAFT to minimize disruption later.
Solution: renumber the socket options
Problem: The new GSSAPI NAMESPACE options should have been
added to the DRAFT section of the API so they can be changed
until stabilized.
Solution:
- Move defines to the DRAFT section of zmq.h
- Duplicate them in zmq_draft.h, as is the local custom
- Compile only if defined (ZMQ_BUILD_DRAFT_API)
- Refactor internals slightly to avoid #ifdef hell
Problem: principals are looked up unconditionally
with the GSS_C_NT_HOSTBASED_SERVICE name type.
Solution: Add two new socket options to set the name type
for ZMQ_GSSAPI_PRINCIPAL and ZMQ_GSSAPI_SERVICE_PRINCIPAL:
ZMQ_GSSAPI_PRINCIPAL_NAMETYPE
ZMQ_GSSAPI_SERVICE_PRINCIPAL_NAMETYPE
They take an integer argument which must be one of
ZMQ_GSSAPI_NT_HOSTBASED (0) - default
ZMQ_GSSAPI_NT_USER_NAME (1)
ZMQ_GSSAPI_NT_KRB5_PRINCIPAL (2)
These correspond to GSSAPI name types of:
GSS_C_NT_HOSTBASED_SERVICE
GSS_C_NT_USER_NAME
GSS_KRB5_NT_PRINCIPAL_NAME
Fixes#2542
- Moved new events in draft section + added to zmq_draft.h
- Removed the remainning tabs
- Reverted the hard error (back to soft error) in curve_server.cpp
=> The feature doesn't works anymore
Added two new monitoring events:
- ZMQ_EVENT_HANDSHAKE_SUCCEED is raised once the encryption handshake succeed
- ZMQ_EVENT_HANDSHAKE_FAILED is raised when it failed
Both events are raised on server and client side.
