Hi Fabien, >> +Bit 1 (LABEL): _This message part is not part of the original >> +message._ A value of 1 indicate a message part that weren't part >> of +the original stream. They are used internally by the >> transport to +indicate, for example, the origin of a message. + >> +Bits 2-7: _Reserved_. Bits 1-7 are reserved for future expansion >> and MUST be set to zero. >> >> It should be explained how LABEL flag interacts with MORE flag. I >> would propose something like this: >> >> 1. Labels always occur at the beginning of the message. If label >> appears elsewhere in the message, the message is malformed. > > In present use-case (routing), that's true. Not so sure about future > use-case but I can't tell why it couldn't be always as start > neither.
It's matter of good design. Message envelope dispersed throughout the message violates clean layering. Additionally, it is a nightmare to parse at wire speed. >> 2. Labels never have MORE flags set. Combination of LAVEL and MORE >> on the same message part makes the message malformed. > > Make it harder to implement queuing device and require the flag to be > either exposed externally or to change the behavior of the > ZMQ_RCVMORE getsockopt. Also, mutually exclusive flags are usually a > bad smell (mean they lack orthogonality). So, -1 for me here. The orthogonality is what should be deliberately avoided here. Note that LABEL flag and MORE flag live at different layers. LABEL flag is 0MQ flag, while MORE is an application flag. You can think of it as user-defined multi-part message being taken as atomic unit and labeled with various labels by 0MQ. The two should never overlap. Unfortunately, backward compatibility concerns force us to mix the two flags in a single layer, which makes the above non-obvious. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
