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

[Chuck Remes]

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...

cr