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.
