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.
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_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
contributors and doesn't reflect the real process. I've taken out all named
authors and referred to the contribution policy. Hopefully this will improve
the contributions to the man pages.
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.
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 there was no distinction between message parts used by 0MQ
and message parts used by user. Now, the message parts used by 0MQ
are marked as 'LABEL'.
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>
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>
