With a msg_t size of 64 bytes, it becomes possible to embedd the content_t's members
struct for large messages directly in the msg_t. This saves the dynamic allocation
of content_t obejcts when using msg_t::init_data.
content_t contains a zmq::atomic_counter_t object which is not a POD in C++98
and thus it cannot be used as a member of the union u. To bypass this, C++11
is used which has relaxed rules for POD and atomic_counter is a C++11-POD. An
alternative would have been to make atomic_counter a classical POD by removing
constructors and all private member functions, i.e. have a struct and free functions
to manipulate it.
A new msg_t::init function is added which decides to either to copy the data for size<64 bytes
or use msg_t::init_data to do zero-copy initialization.
Of course people still "can" distributed the sources under the
LGPLv3. However we provide COPYING.LESSER with additional grants.
Solution: specify these grants in the header of each source file.
Libzmq uses C++ standard library features, so users of it should link
against that as well when statically linking.
Add it to Libs.private so users using pkg-config automatically gets the
correct linker flags.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is a silly assertion that causes problems if libzmq.dll is
called in some esoteric ways.
Solution: if the shutdown code detects WSANOTINITIALISED, then
exit silently.
Fixes#1377Fixes#1144
* There is no clear reason why the map should hold const std::strings
* This class is never derived, there doesn't seem to be a compelling
reason to ever do so, so no need to make virtual members
* In general const member data is an anti-pattern, the *only* reason
is to prevent assignability, and the accepted idiom for that is to
to declare the assigment operator private. This change does so, and
also prevents copy construction.
ZMQ_INVERT_MATCHING reverses the PUB/SUB prefix matching. The subscription
list becomes a rejection list. The PUB socket sends messages to all
connected (X)SUB sockets that do not have any matching subscription.
Whenever the option is used on a PUB/XPUB socket, any connecting SUB
sockets must also set it or they will reject everything the publisher
sends them. XSUB sockets are unaffected because they do not filter out
incoming messages.
Symptom is that ZMQ_STREAM sockets in 4.1.0 and 4.1.1 generate zero
sized messages on each new connection, unlike 4.0.x which did not do
this.
Person who made this commit also changed test cases so that contract
breakage did not show. Same person was later banned for persistently
poor form in CZMQ contributions.
Solution: enable connect notifications on ZMQ_STREAM sockets using a
new ZMQ_STREAM_NOTIFY setting. By default, socket does not deliver
notifications, and behaves as in 4.0.x.
Fixes#1316
When pipe::write succeeds, it takes control of the message's data buffer.
When it fails, it has not taken control. The caller should clean up the
message appropriately (msg::close).
pipe_t.write only takes control of the underlying message memory when it
succeeds. When it returns failure, we must close the message ourselves to
clean up that memory.
This patch is sponsored by FarSounder, Inc (farsounder.com)
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
Increasing it would have at least two benefits -
* More messages would be 'VSM' messages, so it would reduce allocation
overhead a bit.
* Remove any chance of false sharing of things that are, by design,
pushed by value onto a ypipe_t<msg_t> which is shared between two threads.
The only downside I see is slightly increased memory consumption on memory
constrained applications.
- Full discussion of this rationale is part of issue #1295
zmq_atomic_counter_dec returned a 'bool' value, yet this isn't
defined by standard, so causes compile errors in upstream code.
Solution: return an int that can be safely converted to bool if
needed by bindings.
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.
E.g. when server is not configured, and client tries PLAIN security,
there is no hint of why this does not work.
Solution: add debugging output for this case. Note that the various
debugging outputs for security failures should probably be sent to
an inproc monitor of some kind.
auth mechanisms were only enabled when ZMTP handshake
is latest version, meaning that connections from old sockets
would skip authentication altogether
Solution: set defaults back to infinity, and add new context
option, ZMQ_BLOCKY that the user can set to false to get a
less surprising behavior on context termination. Eg.
zmq_ctx_set (ctx, ZMQ_BLOCKY, false);
There are two todo comments in curve_client.cpp and curve_server.cpp that suggest
checking the return code of sodium_init() call. sodium_init() returns -1 on error,
0 on success and 1 if it has been called before and is already initalized:
https://github.com/jedisct1/libsodium/blob/master/src/libsodium/sodium/core.c
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.
For OS X, the microseconds field is implemented as an int type. The implicit narrowing in the initializer list throws a compiler error for some compilers with C++11 support turned on. The specific error message is: "error: non-constant-expression cannot be narrowed from type 'long' to '__darwin_suseconds_t' (aka 'int') in initializer list [-Wc++11-narrowing]".
Tested on Clang 5.1.0 and Mac OS X 10.9.4.
When Curve authentication is used, libsodium opens a file
descriptor to /dev/urandom to generate random bytes. When
the ZMQ context terminates, it should ensure that file gets
closed.
It's bad practice to start by testing all exceptional conditions
and then dropping through to the 'normal' condition. Apart from
being inefficient, it's deceptive to the user. Conditional code
should always try to show the natural expectation of the code,
with exceptional cases coming last.
Solution: clean up this code.
