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
Reaper thread destroys the socket asynchronously.
zmq_term() can be interrupted by a signal (EINTR).
zmq_socket() will return ETERM after zmq_term() was called.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
- Clarify ZMQ_LINGER, zmq_close (), zmq_term () relationship
- New socket options
- Clarify thread safety of sockets and migration between threads
- Other minor and spelling fixes
Signed-off-by: Martin Lucina <mato@kotelna.sk>
