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. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
