Solution: add ZMQ_ZAP_ENFORCE_DOMAIN to hide backward incompatible
change and make it disabled by default.
In a future release that breaks API compatibility we can then switch
the default to enabled in order to achieve full RFC compatibility.
Fixes#2762
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
Linux now supports Virtual Routing and Forwarding (VRF) as per:
https://www.kernel.org/doc/Documentation/networking/vrf.txt
In order for an application to bind or connect to a socket with an
address in a VRF, they need to first bind the socket to the VRF device:
setsockopt(sd, SOL_SOCKET, SO_BINDTODEVICE, dev, strlen(dev)+1);
Note "dev" is the VRF device, eg. VRF "blue", rather than an interface
enslaved to the VRF.
Add a new socket option, ZMQ_BINDTODEVICE, to bind a socket to a device.
In general, if a socket is bound to a device, eg. an interface, only
packets received from that particular device are processed by the socket.
If device is a VRF device, then subsequent binds/connects to that socket
use addresses in the VRF routing table.
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`
Problem: GSSAPI NAMETYPE options were not documented in man
pages for zmq_getsockopt() and zmq_setsockopt().
Solution: add new options to these manual pages.
Problem: the ZMQ_GSSAPI_PRINCIPAL socket option is described
as mandatory in the zmq_gssapi(7) manual page. In fact it
is optional.
Solution: Describe ZMQ_GSSAPI_PRINCIPAL as optional.
If unspecified, default credentials are used.
Solution: add a note pointing out that when new events are added the
ZMQ_EVENT_ALL mask will start returning them, so applications that
can't handle that transparently should not use it and instead pick
only the event types they want.
Creating a new event type and having monitors with ZMQ_EVENT_ALL
return them will not be considered a backward incompatible change
even though the flow of events will change.
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.
Solution:
- Update formatting and remove redundant parts from ZMQ_PROBE_ROUTER,
ZMQ_USE_FD, ZMQ_TCP_MAXRT, ZMQ_TCP_TOS
- Only cosmetic changes to the content
- These changes already merged on api.zeromq.org by me
Problem: when using ZMQ_REQ_RELAXED + ZMQ_REQ_CORRELATE and two 'send' are
executed in a row and no server is available at the time of the sends,
then the internal request_id used to identify messages gets corrupted and
the two messages end up with the same request_id. The correlation no
longer works in that case and you may end up with the wrong message.
Solution: make a copy of the request_id instance member before sending it
down the pipe.
Solution: add the document files to the MAN_DOC and MAN_HTML targets
in doc/Makefile.am only if BUILD_DOC and INSTALL_MAN are set,
otherwise leave the targets empty to avoid errors in make distcheck.
And I'm on a reasonably sized laptop. I think allocating INT_MAX
memory is dangerous in a test case.
Solution: expose this as a context option. I've used ZMQ_MAX_MSGSZ
and documented it and implemented the API. However I don't know how
to get the parent context for a socket, so the code in zmq.cpp is
still unfinished.
