Solution: a new socket type, called PEER. Very similar to SERVER, but can only connect to other PEERs. Also a new zmq_connect_peer method, that connect and return a routing-id in thread-safe and atomic operation
Solution: fix handling of _starting and _terminate flags
Add tests for this situation.
Clarify documentation of zmq_ctx_shutdown and zmq_socket.
Fixes#3792
Solution: Reflect real behavior of sockets blocking on send operations
Sockets that block in mute state only block when no peer is available if
the transport is connection-oriented and the ZMQ_IMMEDIATE socket option
is set.
group being a `char *` is logically a text type, which needs an encoding.
Declare in the API that groups shall be UTF8-encoded,
matching the `zmq_msg_gets` API, which is the other user-facing `char *` API,
which has the same definition.
This allows bindings to provide text-type APIs,
which they cannot do if arbitrary bytes are allowed
Solution:
* Document the new behaviour when generating 'ZMQ_POLLOUT' events
for ZMQ_ROUTER sockets with 'ZMQ_ROUTER_MANDATORY' set to `1`
* Add clarifications for 'ZMQ_ROUTER' socket when
'ZMQ_ROUTER_MANDATORY' is set to `1`
Solution: fix it.
The documentation first states that the ZMQ_SNDMORE flag is ignored on
data frames. Then it states that omitting the ZMQ_SNDMORE flag has
consequences. The example HTTP server code further muddies the situation
with a similar comment.
The implementation of ZMQ_STREAM only accepts two-part messages.
The first part is an identity frame while the second and last part is
the data frame.
As with any multipart message, all parts except the last need the
ZMQ_SNDMORE flag. The second and last part would normally omit the
ZMQ_SNDMORE flag to mark the end of the multipart message.
However, the ZMQ_STREAM implementation ignores the ZMQ_SNDMORE flag on
the data frame rather than requiring that it be omitted. The latter
behaviour would have been more consistent with the other ZeroMQ
sockets.
REQ-REP barely work, and DEALER-ROUTER are misnamed. As we move to
formalizing CLIENT-SERVER, we can deprecate request-reply.
Solution: move this section to the end of the man page, and mark as
"will be deprecated".
Issues adressed:
- The actual data was never read from the socket, causing all even
numbered loop iterations to fail
- The socket variable was called server once
When a ZMQ_STREAM socket connection is broken (intentionally, via `shutdown()`
or accidentally via client crash or network failure), there is no way for the
application to dertermine that it should drop per-connection data (such as
buffers).
This contribution makes sure the application receives a 0-length message to
notify it that the connection has been broken. This is symmetric with the
process of closing the connection from within the application (where the
application sends a 0-length message to tell ZeroMQ to close the connection).
Conflicts:
CMakeLists.txt
- designed for TCP clients and servers
- added HTTP client / server example in tests/test_stream.cpp
- same as ZMQ_ROUTER + ZMQ_ROUTER_RAW + ZMQ_ROUTER_MANDATORY
- includes b893ce set ZMQ_IDENTITY on outgoing connect
- deprecates ZMQ_ROUTER_RAW
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.
zmq::xpub_t::xread_activated() – change to process messages without 0
or 1 prefix, but without affecting subscriptions
zmq::xsub_t::xsend() – change to send rather than discard messages
without 0 or 1 prefix, but without affecting subscriptions
Update documentation
- reverted commit 941be8d2175332cb720f390f93d07a0870db8824.
- fixed zmq_device implementation for latest socket_base class
- added back zmq_device.3 man page
