[zeromq-dev] Question: release policies and v3.x

Chuck Remes cremes.devlist at mac.com
Wed Jul 20 10:42:00 CEST 2011

On Jul 19, 2011, at 11:52 PM, Brian Granger wrote:

> On Mon, Jul 18, 2011 at 5:26 AM, Pieter Hintjens <ph at imatix.com> wrote:
>> Hi all,
>> A question to the list about release policies[1] and the 3.x development.
>> Background: we are removing ZMQ_IDENTITY from the product, it's a
>> necessary step to continuing to improve the product. (Incidentally, if
>> you are using ZMQ_IDENTITY, let us know your use case).
> We use ZMQ_IDENTITY extensively to route to specific hosts.  We also
> do this in a chained, multihop manner as well.  We have a massive,
> complex architecture that uses it in multiple contexts.  Here is a web
> page that documents (with nice diagrams!) our zmq socket architecture:
> http://ipython.org/ipython-doc/dev/development/parallel_connections.html
> In general anywhere you see an XREP/XREQ pair, we are using ZMQ_IDENTITY.

Lovely stuff. I really dig those diagrams!

Now, what I am about to say may be completely wrong. As I've followed this issue over the last several weeks, I have always thought the problem that Martin had with ZMQ_IDENTITY was the ability to set a *custom* identity. Using a byte array of arbitrary length (up to 255 bytes) was holding him back from making some design improvements. I think he wanted to replace the 255 byte identity with a 32-bit or 64-bit number.

So, if I am right about this so far, then we would only be losing ZMQ_IDENTITY for zmq_setsockopt(). It would still exist for zmq_getsockopt() because the identity would always be generated by the library.

If this is correct so far, then your use-case would continue to function. You could still route to specific hosts by their identity. The new complexity would be somehow mapping these library-generated identities to the actual endpoints. Judging by the diagrams, you aren't afraid of using dedicated sockets for passing specific bits of information around.

Corrections welcome...


More information about the zeromq-dev mailing list