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
Firstly, only a few types are defined, leaving it hard for higher layers
to complete the set. Secondly, the code incorrectly tries to use ifndef
to avoid re-defining typedefs, which does not work in C.
Solution: define all types, unconditionally for all MSVC compilers.
Additionally, define ZMQ_DEFINED_STDINT that tells higher layers that we
already defined these integer types.
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.
