[zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk
Thomas Rodgers
rodgert at twrodgers.com
Fri Jan 9 18:00:19 CET 2015
I would like to propose removing this option before it becomes part of an
officially released API, but I would like to reassurance that this is an
appropriate course of action before doing so.
My reasoning for removing it is as follows -
* It is the only option to zmq_getsockopt() that treats option_value as a
value/result parameter, all others treat option_value as strictly a result
parameter.
* A brief survey of the Posix getsockopt() API shows a similar lack of
using option_value as a value/result parameter.
* The original implementation requires the caller to ensure that the
returned buffer is sufficient to hold an fd_t, but fd_t is not part of
ZeroMQ's public API. It is conditionally defined by platform and on Windows
has two potential definitions.
* I'm not comfortable with this blind faith assignment through a pointer,
so I submitted a length check change. Unfortunately this introduces a whole
new class of potential usage problems for this option.
* I don't know what the intended use case for the option is, but I infer
from the test_id2fd test case, that is to build a map of router identity to
fd, perhaps to pass fd to getpeername(2) and build a map of identity to
peername. If this is indeed the case, this use case is already handled by
calling zmq_msg_get(&part, ZMQ_SRCFD), on the message part containing the
identity frame.
What am I missing here?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150109/f4f38922/attachment.htm>
More information about the zeromq-dev
mailing list