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.
Users who need e.g. zmq_curve_keypair() have to remember to include
zmq_utils.h, which is counter-intuitive. The whole library should be
represented by a single include file.
Solution: merge all contents of zmq_utils.h into zmq.h, and deprecate
zmq_utils.h. Existing apps can continue unchanged. New apps can ignore
zmq_utils.h completely.
This is still raw and experimental.
To connect through a SOCKS proxy, set ZMQ_SOCKS_PROXY socket option on
socket before issuing a connect call, e.g.:
zmq_setsockopt (s, ZMQ_SOCKS_PROXY,
"127.0.0.1:22222", strlen ("127.0.0.1:22222"));
zmq_connect (s, "tcp://127.0.0.1:5555");
Known limitations:
- only SOCKS version 5 supported
- authentication not supported
- new option is still undocumented
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.
Added modifiers reflect the following properties:
- zmq_msg_gets () does not mutate property parameter
- zmq_msg_gets () returns a pointer to memory the caller should not
modify
Specifically:
* zmq_event_t should not be used internally in libzmq, it was
meant to be an outward facing structure.
* In 4.x, zmq_event_t does not correspond to monitor events, so
I removed the structure entirely.
* man page for zmq_socket_monitor is incomplete and the example
code was particularly nasty.
* test_monitor.cpp needed rewriting, it was not clean.
The new options allows querying the maximum allowed number of sockets.
This is system dependent and cannot be encoded in the include file as a
preprocessor macro: for ZMQ_USE_SELECT, this depends on the FD_SETSIZE
macro at time of library compilation, not at time of include file use.
- renamed to ZMQ_CONNECT_RID
- fixed whitespace malformating around previous patch
- renamamed next_peer_id to next_rid in preparation for
larger rename of IDENTITY to ROUTING_ID
Note: ZMQ_CONNECT_RID has no test case and no entry in the man
page, as yet.
This change simply provides the user with a socket option that sets a user defined name of the next outbound connection:
zmq_setsockopt(routerSock,ZMQ_NEXT_IDENTITY,"myname",6);
if(0 > zmq_connect(routerSock,"tcp://127.0.0.1:1234")) return 1;
ret = zmq_send(routerSock,"myname",6,ZMQ_SNDMORE);
zmq_send(routerSock,b.mem,b.used,0);
In this example, the socket is immediately given the name "myname", and is capable of immediately sending traffic.
This approach is more effective in three ways:
1) It prevents all sorts of malicious peer naming attacks that can cause undefined behavior in existing ROUTER connections. (Two connections are made that both transmit the same name to the ROUTER, the ROUTER behavior is undefined)
2) It allows immediate control of connections made to external parties for STREAM sockets. Something that is not possible right now. Before an outbound connection had no name for STREAM or ROUTER sockets because outbound connections cannot be sent to without first receiving traffic.
3) It is simpler and more general than expecting two ROUTER sockets to handshake on assigned connection names. Plus it allows inline sending to new connections on ROUTER.
- 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?
Another take on LIBZMQ-568 to allow filtering IPC connections, this time
using ZAP. This change is backward compatible. If the
ZMQ_ZAP_IPC_CREDS option is set, the user, group, and process IDs of the
peer process are appended to the address (separated by colons) of a ZAP
request; otherwise, nothing changes. See LIBZMQ-568 and zmq_setsockopt
documentation for more information.
* 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.
* Removed redundant Z85 code and include files from project
* Simplified use of headers in test cases (now they all just use testutil.hpp)
* Export zmq_z85_encode() and zmq_z85_decode() in API
* Added man pages for these two functions
* This is passed to the ZAP handler in the 'domain' field
* If not set, or empty, then NULL security does not call the ZAP handler
* This resolves the phantom ZAP request syndrome seen with sockets where
security was never intended (e.g. in test cases)
* This means if you install a ZAP handler, it will not get any requests
for new connections until you take some explicit action, which can be
setting a username/password for PLAIN, a key for CURVE, or the domain
for NULL.
- Split off NULL security check from PLAIN
- Cleaned up test_linger code a little
- Got all tests to pass, added TODOs for outstanding issues
- Added ZAP authentication for NULL test case
- NULL mechanism was not passing server identity - fixed
- cleaned up test_security_plain and removed option double-checks (made code ugly)
- lowered timeout on expect_bounce_fail to 150 msec to speed up checks
- removed all sleeps from test_fork and simplified code (it still passes :-)
This allows making a new request on a REQ socket by sending a new
message. Without the option set, calling send() after the first message
is done will continue to return an EFSM error.
It's useful for when a REQ is not getting a response. Previously that
meant creating a new socket or switching to DEALER.
* Documentation:
The default behavior of REQ sockets is to rely on the ordering of messages
to match requests and responses and that is usually sufficient. When this option
is set to 1, the REQ socket will prefix outgoing messages with an extra frame
containing a request id. That means the full message is (request id, 0,
user frames...). The REQ socket will discard all incoming messages that don't
begin with these two frames.
* Behavior change: When a REQ socket gets an invalid reply, it used to
discard the message and return EAGAIN. REQ sockets still discard
invalid messages, but keep looking at the next one automatically
until a good one is found or there are no more messages.
* Add test_req_request_ids.
- designed for TCP clients and servers
- added HTTP client / server example in tests/test_stream.cpp
- same as ZMQ_ROUTER + ZMQ_ROUTER_RAW + ZMQ_ROUTER_MANDATORY
- includes b893ce set ZMQ_IDENTITY on outgoing connect
- deprecates ZMQ_ROUTER_RAW
- ZMQ_CURVE_PUBLICKEY for clients and servers
- ZMQ_CURVE_SECRETKEY for clients
- ZMQ_CURVE_SERVERKEY for clients
- ZMQ_CURVE_SERVER for servers
- added tools/curve_keygen.c as example
- updated man pages
* ZMQ_PLAIN_SERVER, ZMQ_PLAIN_USERNAME, ZMQ_PLAIN_PASSWORD options
* Man page changes to zmq_setsockopt and zmq_getsockopt
* Man pages for ZMQ_NULL, ZMQ_PLAIN, and ZMQ_CURVE
* Test program test_security
