The example is applications passing invalid arguments to a socket option
and then failing to check the return code. The results can be very hard
to diagnose. Here are some threads that show the pain this causes:
* https://github.com/zeromq/zyre/issues/179
* http://lists.zeromq.org/pipermail/zeromq-dev/2014-June/026388.html
One common argument is that a library should never assert, and should
pass errors back to the calling application. The counter argument is
that when an application is broken enough to pass garbage to libzmq,
it cannot be trusted to handle the resulting errors properly. Empirical
evidence from CZMQ, where we systematically assert on bad arguments, is
that this militant approach makes applications more, not less, robust.
I don't see any valid use cases for returning errors on bad arguments,
with one exception: zmq_setsockopt can be used to probe whether libzmq
was e.g. built with CURVE security. I'd argue that it's nasty to use a
side effect like this. If apps need to probe how libzmq was built, this
should be done explicitly, and for ALL build options, not just CURVE.
There are/were no libzmq test cases that check the return code for an
invalid option.
For now I've enabled militant assertions using --with-militant at
configure time. However I'd like to make this the default setting.
Applications that use ZMQ_IDENTITY can be trapped by the artificial
restriction on not using a binary zero as first byte. It's specially
nasty on random generated identities, e.g. UUIDs, as the chance of a
binary zero is low, so it will pass 255 out of 256 times.
Solution: remove the restriction.
- 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.
* 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
On ZMQ_CURVE_xxxKEY fetches, would return 41 bytes into caller's 40-byte
buffer. Now these fetches only return 41 bytes if the caller explicitly
provides a 41-byte buffer (i.e. the option size is 41).
* 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.
These were exposed to users, but have subsequently been removed as
sockopts. They are currently only being used by ZAP, so I've moved it to
a simpl function call (actually it's only used in one case even in that,
so there may be a further simplification possible there).
The use of binary for CURVE keys is painful; you cannot easily copy
these in e.g. email, or use them directly in source code. There are
various encoding possibilities. Base16 and Base64 are not optimal.
Ascii85 is not safe for source (it generates quotes and escapes).
So, I've designed a new Base85 encoding, Z85, which is safe to use
in code and elsewhere, and I've modified libzmq to use this where
it also uses binary keys (in get/setsockopt).
Very simply, if you use a 32-byte value, it's Base256 (binary),
and if you use a 40-byte value, it's Base85 (Z85).
I've put the Z85 codec into z85_codec.hpp, it's not elegant C++
but it is minimal and it works. Feel free to rewrap as a real class
if this annoys you.
- 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
- we need to switch to PLAIN according to options.mechanism
- we need to catch case when both peers are as-server (or neither is)
- and to use username/password from options, for client
* 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
Copyrights had become ads for Sustrik's corporate sponsors, going against the original
agreement to share copyrights with the community (that agreement was: one line stating
iMatix copyright + one reference to AUTHORS file). The proliferation of corporate ads
is also unfair to the many individual authors. I've removed ALL corporate title from
the source files so the copyright statements can now be centralized in AUTHORS and
source files can be properly updated on an annual basis.
- Created a new option ZMQ_ROUTER_RAW_SOCK
- Added new raw_encoder and raw_decoder to receive and send messages in raw form to remote client
- Added test case file tests/test_raw_sock.cpp
o To create a raw router sock set the ZMQ_ROUTER_RAW_SOCK option
o ZMQ_MSGMORE flag is ignored for non-id messages
o To terminate a remote connection send id message followed by zero length data message
This patch, salvaged from a trainwreck accidental merge earlier, adds a
new sockopt, ZMQ_DELAY_ATTACH_ON_CONNECT which prevents a end point
being available to push messages to until it has fully connected, making
connect work more like bind. This also applies to reconnecting sockets,
which may cause message loss of in-queue messages, so it is sensible to
use this in conjunction with a low HWM and potentially an alternative
acknowledgement path.
Notes on most of the individual commits can be found the repository log.
This patch adds a sockopt ZMQ_DELAY_ATTACH_ON_CONNECT, which if set to 1 will attempt to preempt this behavior. It does this by extending the use of the session_base to include in the outbound as well as the inbound pipe, and only associates the pipe with the socket once it receives the connected callback via a process_attach message. This works, and a test has been added to show so, but may introduce unexpected complications. The shutdown logic in this class has become marginally more awkward because of this, requiring the session to serve as the sink for both pipes if shutdown occurs with a still-connecting pipe in place. It is also possible there could be issues around flushing the messages, but as I could not directly think how to create such an issue I have not written any code with regards to that.
The documentation has been updated to reflect the change, but please do check over the code and test and review.
The current ZMQ_MONITOR code does not compile in gcc 4.7, as -pedantic
and -Werror are enabled, and ISO C++ doesn't allow casting between
normal pointers (void*) and function pointers, as pedantically their
size could be different. This caused the library not compilable. This
commit workaround the problem by introducing one more indirection, i.e.
instead of calling
(void *)listener
which is an error, we have to use
*(void **)&listener
which is an undefined behavior :) but works on most platforms
Also, `optval_ = monitor` will not set the parameter in getsockopt(),
and the extra casting caused the LHS to be an rvalue which again makes
the code not compilable. The proper way is to pass a pointer of function
pointer and assign with indirection, i.e. `*optval_ = monitor`.
Also, fixed an asciidoc error in zmq_getsockopt.txt because the `~~~~`
is too long.
Assign arbitrary number of filters that will be applied for each new TCP transport
connection on a listening socket.
If no filters applied, then TCP transport allows connections from any ip.
If at least one filter is applied then new connection source ip should be matched.
To clear all filters call zmq_setsockopt(socket, ZMQ_TCP_ACCEPT_FILTER, NULL, 0).
Filter is a null-terminated string with ipv6 or ipv4 CIDR.
For example:
localhost
127.0.0.1
mail.ru/24
::1
::1/128
3ffe:1::
3ffe:1::/56
Returns -1 if the filter couldn't be assigned(format error or ipv6 filter with ZMQ_IPV4ONLY set)
P.S.
The only thing that worries me is that I had to re-enable 'default assign by reference constructor/operator'
for 'tcp_address_t' (and for my inherited class tcp_address_mask_t) to store it in std::vector in 'options_t'...
* Implemented new ctx API (_new, _destroy, _get, _set)
* Removed 'typesafe' macros from zmq.h
* Added support for MAX_SOCKETS (was tied into change for #337)
* Created new man pages
However, the "durable socket" behaviour wasn't re-added.
Identities are used solely for routing in REQ/REP pattern.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
This patch is meant to prevent users from running out of memory
when using 0MQ in the default configuration.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
At this point option exists, is documented and can be set,
however, it has no effect.
Signed-off-by: Steven McCoy <steven.mccoy@miru.hk>
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
The filtering is now done depending on the socket type. SUB socket
filters the messages (end-to-end filtering) while XSUB relies
on upstream nodes to do (imprefect) filtering.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
So far the requests in req/rep pattern were delivered to and processed
by worker even though the original requester was dead. Thus,
the worker processing replies with noone to deliver results to.
This optimisation drops requests in two situations:
1. Queued inbound requests in XREP socket when peer disconnects.
2. Queued outbound requests in XREQ when socket is closed.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
This option is a performance tweak. In devices XSUB socket filters
the messages just to send them to XPUB socket which filters them
once more. Setting ZMQ_FILTER option to 0 allows to switch the
filtering in XSUB socket off.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
So far, there was a pair of unidirectional pipes between a socket
and a session (or an inproc peer). This resulted in complex
problems with half-closed states and tracking which inpipe
corresponds to which outpipe.
This patch doesn't add any functionality in itself, but is
essential for further work on features like subscription
forwarding.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
This patch addresses serveral issues:
1. It gathers message related functionality scattered over whole
codebase into a single class.
2. It makes zmq_msg_t an opaque datatype. Internals of the class
don't pollute zmq.h header file.
3. zmq_msg_t size decreases from 48 to 32 bytes. That saves ~33%
of memory in scenarios with large amount of small messages.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
These new options allow to control the maximum size of the
inbound and outbound message pipe separately.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
On-disk storage should be implemented in devices rather than
in 0MQ core. 0MQ is a networking library and there's no point
in storing network buffers on disk.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
Multicast loopback is not a real multicast, rather a kernel-space
simulation. Moreover, it tends to be rather unreliable and lossy.
Removing the option will force users to use transports better
suited for the job, such as inproc or ipc.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
The new option allows user to guard against peers sending
oversized messages. Connection to peer sending oversized message
is dropped.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
For very high-speed message systems, the memory used for recovery can get to
be very large. The corrent limitation on that reduction is the ZMQ_RECOVERY_IVL
of 1 sec. I added in an additional option ZMQ_RECOVERY_IVL_MSEC, which is the
Recovery Interval in milliseconds. If used, this will override the previous
one, and allow you to set a sub-second recovery interval. If not set, the
default behavior is to use ZMQ_RECOVERY_IVL.
Signed-off-by: Bob Beaty <rbeaty@peak6.com>
1. ZMQ_LINGER option can be set/get
2. options are part of own_t base class rather than being declared
separately by individual objects
3. Linger option is propagated with "term" command so that the
newest value of it is used rather than the stored old one.
4. Session sets the linger timer if needed and terminates
as soon as it expires.
5. Corresponding documentation updated.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
This commit introduces the necessary changes necessary
for implementing flow control. None of the socket types
implements the flow control yet. The code will crash when
the flow control is enabled and the thw lwm is reached.
The following commits will add flow-control support for
individual socket types.
C and C++ headers moved from bindings/ to include/, bindings/ removed
--with-c and --with-cpp options to configure removed, C and C++ now built
and installed by default
