[zeromq-dev] ZMTP/1.1, comments

Martin Hurton hurtonm at gmail.com
Mon Aug 13 12:31:30 CEST 2012

I think there is a way how we can move from ZTP/1.0 toward a protocol
with proper versioning and keep backward compatibility.
We need to define a new VERSION bit in the flags field.

Let's say the identity is n bytes long.
At the beginning, each peer sends the following two bytes: (n + 1),
VERSION and waits until it receives those two bytes from the peer.
After it has received them, it inspects the 2nd byte and checks the
VERSION bit. If it's 1, it knows that its peer suggest to use
versioned protocol.
The current v3 and the v2 sends the whole greeting message at once
(those 2 bytes + the identity bytes), so its peer can detect it's
using unversioned protocol and sent the remaining bytes of the
greeting, as required by ZTP/1.0.
If the VERSION bit is 1, we can send some HELLO message with the
protocol version number and other info, as required.

One problem with this scehme is the VERSION bit.
Older versions of library set some unused bits to 1
But I think we can use either share bit, which is use internally and
seems that that one was always cleared, or MORE bit, which, it seems,
was not set for greeting frame. This needs to be investigated.
If neither of those bits can be used, we can still use some bit
pattern that never occurred in the flag field in the past.

- the support of older peers increases the latency of initial handshake
- increases code complexity somewhat

What do you think? Is there something that would prevent the
interoperability between old and new peers?

- Martin

On Mon, Aug 13, 2012 at 3:49 AM, Pieter Hintjens <ph at imatix.com> wrote:
> On Sun, Aug 12, 2012 at 9:18 PM, Martin Hurton <hurtonm at gmail.com> wrote:
>> The challenge frame is specified as:
>>     challenge  = %x04 %x00 version socket-type more
> Seems the challenge should be:
>     %x03 more version socket-type
>> Also, the specification defines the LABEL bit which should be set to 1
>> to mark label frame (I think both identity and anonymous frames
>> qualify as label frames).
> Good point. I'll make that change too.
> What's more difficult is to ensure that existing (deployed) 0MQ
> applications deal with a ZMTP/1.1 connection safely. If we can't do
> this, it's going to be impossible to connect old and new together.
> If we can't implement ZMTP/1.1 than (a) I'm going to reproach Martin
> Sustrik for refusing to help make a proper protocol ages ago when we
> had the chance and (b) we need to at least make PUB sockets smart
> enough to know whether they're talking to new XSUBs or old SUBs.
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list