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

[MinRK]

On Thu, Oct 27, 2011 at 11:06, Gregory Szorc <gregory.szorc at gmail.com>wrote:

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

And the experimental branch adds RCVCMD.  I think a single MSGFLAGS sockopt
that just returns the bitfield would be great.


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

We've written a relatively substantial application based on
identity-routing, and I can
see that some of the messaging code would have been made simpler if the
routing part of the message
were immediately distinguishable, as it in 3.0.  Of course, now that we are
in production
mode, I will have to figure out how to support both, and for now we have
switched all
the sockets that really should be XREP to ROUTER, which means our app works
on
3.0 just fine until I figure out how to update to using labels, while still
working properly without them.

-MinRK


>
> 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
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20111027/a2542438/attachment.htm>