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
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.
As libzmq is compiled with optional transports and security mechanisms,
there is no clean way for applications to determine what capabilities
are actually available in a given libzmq instance.
Solution: provide an API specifically for capability reporting. The
zmq_has () method is meant to be open ended. It accepts a string so
that we can add arbitrary capabilities without breaking existing
applications.
zmq.h also defines ZMQ_HAS_CAPABILITIES when this method is provided.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743508
The ABI in fact changed in two significant ways, one with inproc
connects, and one with socket monitoring
Solution: generate libzmq.so.4.0.0 library instead.
This change should be backported to zeromq-4.x
- renamed test_stream_disconnect_notifications (too long!)
- removed print statements in that test case
- fixed Makefile.am for test_zap_ipc_creds (was not building)
- This seems redundant; is there a use case for NOT providing
the IPC credentials to the ZAP authenticator?
- More, why is IPC authentication done via libzmq instead of ZAP?
Is it because we're missing the transport type on the ZAP request?
* ZMQ_REQ_STRICT was negative option (default 1) which goes against
the standard, where defaults are zero. I renamed this to
ZMQ_REQ_RELAXED.
* ZMQ_REQ_REQUEST_IDS felt clumsy and describes the technical solution
rather than the problem/requirement. I changed to ZMQ_REQ_CORRELATE
which seems more explicit.
- tests that system can provide at least 1,000 sockets
- we could expand on this but this covers the main case of OS/X
having a too-low default limit of 256 handles per process
