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

Martin Sustrik sustrik at 250bpm.com
Sun Sep 18 08:26:55 CEST 2011

On 07/20/2011 10:42 AM, Chuck Remes wrote:

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

The problem is not with having IDs 255 byte long, rather the fact that 
IDs survive the failure of the peer. That means that identity (and 
associated buffer) exists even though the peer does not exists. This 
kond of mix between transient and persistent messaging is causing a 
whole lots of problems. The right solution, IMO is using 0MQ sockets 
only for transient messaging (when peer is restarted it's treated as a 
new peer, not the old one) and build persistent broker-based solutions 
on top of it.

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

No. The identity would be generated by the peer. Ie. socket itself has 
no idea of its identity. When it connects, the peer generates an ID that 
it'll use to refer to that connection.


More information about the zeromq-dev mailing list