[zeromq-dev] Behavior of Labels, Identities, and Socket Types in 3.0

Gregory Szorc gregory.szorc at gmail.com
Thu Oct 27 20:06:54 CEST 2011


On 10/27/11 7:40 AM, Chuck Remes wrote:

> I like the concept of differentiating the envelope/labels from the message body. I would like to keep labels.
>
> Using an empty packet as a delimiter between envelope and body was a good first try, but labels are superior.

I agree.

One nit I have about the current implementation is how you need to 
double dip into getsockopt when reading a multi-part message. On the 
initial message(s), you always need to query LABEL. On the first 
non-label message, you need to getsockopt again to determine if MORE are 
available. On subsequent messages, you can bypass querying for LABEL, as 
all labels must precede regular messages. Is this accurate, or can you 
interleave label and non-label messages? Either way, double dipping 
incurs more function calls, which can't be inlined (assuming a 
dynamically linked libzmq). How about combining both queries into a 
single getsockopt option and have macros for testing the set bitfield?

As for the whole to-label-or-not-to-label argument, as an end user (with 
admittedly not very much skin in the game), I really don't care [too 
much]. 3.0, with a new major version, is certainly the time to make such 
drastic changes. And, as the popularity of the project grows, change now 
will cause less user angst than change later. As long as the 
documentation (everything from man pages to the guide) is proper and the 
upgrade path is well-documented and supported, I'm game.

Going forward, I'd also like to see a more prominent notice that 
versions (like master of 3.0 today) aren't stable and/or are half-baked. 
The README would be a good location for an ALL CAPS WARNING. I realize 
the beta tag implies some of this (but only a short while ago 0MQ was in 
perpetual "stable" beta) and I know there are (probably) plenty of 
warnings on this mailing list and IRC, but people shouldn't have to 
exhaustively read the mailing list or lurk on IRC to discover this, IMO.

Greg





More information about the zeromq-dev mailing list