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.
Solution: change setsockopts on printable keys to expect 41, nor 40
bytes. Code still accepts 40 bytes for compatibility, and copies the
key to a well-terminated string before using it.
Fixes#1148
Updated:
src/thread.cpp: On older z/OS UNIX System Services,
pthread_{get,set}schedparam is not present (searching the
Internet suggests it may be present in later version than
the one being used for z/OS UNIX System Services porting).
Make zmq::thread_t::setSchedulingParameters() a no-op on
z/OS UNIX System Services.
NOTE: pthread_{get,set}schedparam appear to have been introduced
by POSIX.1-2001 or IEEE 1003.1-2004 so may not be universally
available, and thus more platforms may need this "no-op" treatment.
Updated:
src/metdata.hpp: Remove explicit "const" from key of std::map<>
because the key is implicitly const already (see
http://en.cppreference.com/w/cpp/container/map and
http://www.cplusplus.com/reference/map/map/).
On some platforms (such as z/OS UNIX System Services) explicitly
declaring the map key as "const" causes template expansion errors
as it tries to create separate allocators for "const const std::string"
and "const std::string" only to find that they clash. (Presumably
some compilers collapse these into one earlier.)
There are no template expansion errors if the map key is left to be
implicitly const.
Updated:
src/signaler.cpp: Add close_wait_ms() static function to loop
when receiving EAGAIN in response to close(), with ms long
sleeps, up to a maximum limit (default 2000ms == 2 seconds);
used in signaler_t::~signaler_t() destructor.
Rationale: In a real-time environment it is sometime mandatory to tune
threads priority and scheduling policy. This is required by our users
who mixes real-time and server threads within
the same process. It's not planned to support this on non-pthread
platforms (e.g. Windows).
Since https://github.com/zeromq/libzmq/commit/350a1a, TCP addresses
get resolved asynchronously, so zmq_connect no longer returned an
error on incorrect addresses.
This is troublesome since we rely on some error checking to catch
blatant errors.
Solution add some upfront syntax checking that catches at least the
obvious kinds of errors (invalid characters, wrong or missing port
number).
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.
Solution: use same approach as for libsodium/CURVE, i.e. return EINVAL
if the library isn't present when libzmq builds, and the application
still tries to use these options in zmq_getsockopt/setsockopt.
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.
