Custom IDENTITY values are not passed as label values to other sockets in 3.0
Description
Environment
OSX intel, libzmq3_0 master (3.02)
Activity
Martin Sustrik November 5, 2011 at 5:20 PM
This issue should be solved by 3.1 branch which reverts the req/rep protocol to the one used by 2.1.
Martin Sustrik September 27, 2011 at 12:17 PM
+1. It will break backward compatibility though so I would suggest announcing it and discussing it on the mailing list first.
PieterP September 20, 2011 at 8:47 PM
What does "the new 4.x-like protocol" mean? Is this documented somewhere? The main problem here is that many people have never stopped using XREP as a synonym for ROUTER, because it took so long for ROUTER/DEALER to make it into the master. Lots of bindings don't even support ROUTER/DEALER. So people are just learning this. Now, we're switching out the meaning of XREP/XREQ to something not quite documented and not much discussed. It's rather confusing.
Perhaps in 3.x, we should keep XREP/XREQ as pure synonyms for ROUTER/DEALER and keep that behaviour compatible with identities as we know them.
Chuck Remes September 18, 2011 at 1:30 PM
This bug report may be due to a lack of understanding about how these things are supposed to work in 3.0. The man pages make no mention that IDENTITY is only valid for ROUTER/DEALER. I expected IDENTITY to work the same for XREP sockets.
So, perhaps the fix for this is a patch to the documentation so that it is clearer how it is supposed to work.
Martin Sustrik September 18, 2011 at 7:08 AM
IIRC there are ROUTER/DEALER sockets that emulate 2.x behaviour. XREQ/XREP use the new 4.x-like protocol.
If people want only the 2.x style functionality in 3.x, the current XREQ/XREP code can be removed and replaced by ROUTER/DEALER code.
3.0 is supposed to allow custom IDENTITY values like the 2.x branch. This IDENTITY should be passed as the label to other sockets. A C reproduction using a REQ and XREP socket shows that the custom IDENTITY is not sent through from the REQ socket to the XREP socket. Instead it looks like a few (4?) bytes of random binary.