[zeromq-dev] Fwd: 37/ZMTP RFC inconsistencies

Elliot Crosby-McCullough elliot.cm at gmail.com
Tue May 24 08:41:07 CEST 2016


Great, thanks.  All the rest makes sense.

On 24 May 2016 at 06:34, Pieter Hintjens <ph at imatix.com> wrote:

> OK, done here: https://github.com/zeromq/rfc/pull/95
>
> On Mon, May 23, 2016 at 11:11 PM, Elliot Crosby-McCullough <
> elliot.cm at gmail.com> wrote:
>
>> 👍🏻
>>
>> On 23 May 2016 at 21:35, Pieter Hintjens <ph at imatix.com> wrote:
>>
>>> Yes, good catch. I need to double-check that, it may be that with NULL
>>> we can strictly define the server as "binding peer" and client as
>>> "connecting peer" since there's no security relationship.
>>>
>>> On Mon, May 23, 2016 at 7:34 PM, Elliot Crosby-McCullough
>>> <elliot.cm at gmail.com> wrote:
>>> > OK, cool.  Does this line need updating then, as the NULL mechanism now
>>> > describes client and server behaviours with regard to the sequencing of
>>> > READY commands?
>>> >
>>> > https://github.com/zeromq/rfc/blob/master/spec_37.txt#L227
>>> >
>>> > On 23 May 2016 at 18:20, Pieter Hintjens <ph at imatix.com> wrote:
>>> >>
>>> >> The as_server property lets you reverse the usual bind/connect
>>> >> direction so that the client binds and the server connects. Without
>>> >> this, it's per the usual default.
>>> >>
>>> >> On Mon, May 23, 2016 at 2:17 PM, Elliot Crosby-McCullough
>>> >> <elliot.cm at gmail.com> wrote:
>>> >> > Great, thanks.  Since we're talking about a security mechanism that
>>> >> > doesn't
>>> >> > set `as_server` for either peer should I assume that the binding
>>> peer is
>>> >> > the
>>> >> > "server" and the connecting peer is the "client", i.e. standard TCP
>>> >> > terminology?
>>> >> >
>>> >> > On 23 May 2016 at 13:15, Pieter Hintjens <ph at imatix.com> wrote:
>>> >> >>
>>> >> >> I've made changes and sent a PR:
>>> https://github.com/zeromq/rfc/pull/93
>>> >> >>
>>> >> >> On Mon, May 23, 2016 at 2:11 PM, Pieter Hintjens <ph at imatix.com>
>>> wrote:
>>> >> >> > OK, there's an error in the explanation here. It's not
>>> symmetric. The
>>> >> >> > client is the one that needs to send its READY upfront. The
>>> server is
>>> >> >> > the one that checks the READY properties before sending its own
>>> >> >> > READY.
>>> >> >> > The example is correct; the text is not. Thanks for pointing this
>>> >> >> > out.
>>> >> >> >
>>> >> >> >
>>> >> >> > On Mon, May 23, 2016 at 1:54 PM, Elliot Crosby-McCullough
>>> >> >> > <elliot.cm at gmail.com> wrote:
>>> >> >> >> Hi Pieter,
>>> >> >> >>
>>> >> >> >> You're right, I noticed the more detailed description of the
>>> partial
>>> >> >> >> signature read shortly after posting, but I'm still not sure
>>> about
>>> >> >> >> the
>>> >> >> >> worked example.  As I mentioned there's also the conflict
>>> between
>>> >> >> >> waiting
>>> >> >> >> for a READY, validating it, *then* sending your own READY as
>>> per the
>>> >> >> >> worked
>>> >> >> >> example, while the spec says to send READY without waiting for
>>> the
>>> >> >> >> other
>>> >> >> >> side to do so.
>>> >> >> >>
>>> >> >> >> All the best,
>>> >> >> >> Elliot
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> On 22 May 2016 at 19:38, Pieter Hintjens <ph at imatix.com> wrote:
>>> >> >> >>>
>>> >> >> >>> The partial read is to deal with older versions of ZMTP. Peers
>>> that
>>> >> >> >>> do
>>> >> >> >>> this won't deadlock since as soon as they've read the first 11
>>> >> >> >>> bytes
>>> >> >> >>> they can send the rest of their own greeting, then they can
>>> >> >> >>> validate
>>> >> >> >>> the socket type, send READY, then wait for a READY. Peers that
>>> >> >> >>> don't
>>> >> >> >>> do backwards compatibility just send the whole greeting, wait
>>> for
>>> >> >> >>> the
>>> >> >> >>> greeting, validate it, etc.
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>> On Sun, May 22, 2016 at 10:54 AM, Elliot Crosby-McCullough
>>> >> >> >>> <elliot.cm at gmail.com> wrote:
>>> >> >> >>> > Hi there!
>>> >> >> >>> >
>>> >> >> >>> > I'm working my way through an implementation of 37/ZMTP
>>> >> >> >>> > (http://rfc.zeromq.org/spec:37) and there's a few
>>> inconsistencies
>>> >> >> >>> > in
>>> >> >> >>> > the
>>> >> >> >>> > spec, mostly the timing of message exchanges, and how it
>>> differs
>>> >> >> >>> > in
>>> >> >> >>> > the
>>> >> >> >>> > spec
>>> >> >> >>> > proper from the worked example.
>>> >> >> >>> >
>>> >> >> >>> > Here's a couple of quotes where anti-deadlock approaches are
>>> >> >> >>> > discussed:
>>> >> >> >>> >>
>>> >> >> >>> >> A peer that reads a full greeting, including mechanism, MUST
>>> >> >> >>> >> also
>>> >> >> >>> >> send
>>> >> >> >>> >> a
>>> >> >> >>> >> full greeting including mechanism. This avoids deadlocks in
>>> >> >> >>> >> which
>>> >> >> >>> >> two
>>> >> >> >>> >> peers
>>> >> >> >>> >> each wait for the other to divulge the remainder of their
>>> >> >> >>> >> greeting.
>>> >> >> >>> >
>>> >> >> >>> >
>>> >> >> >>> >> Note that to avoid deadlocks, each peer MUST send its READY
>>> >> >> >>> >> command
>>> >> >> >>> >> before
>>> >> >> >>> >> attempting to receive a READY from the other peer. In the
>>> NULL
>>> >> >> >>> >> mechanism,
>>> >> >> >>> >> peers are symmetric.
>>> >> >> >>> >
>>> >> >> >>> >
>>> >> >> >>> > However, the worked example doesn't do this:
>>> >> >> >>> >>
>>> >> >> >>> >> The client sends a partial greeting (11 octets) greeting to
>>> the
>>> >> >> >>> >> server,
>>> >> >> >>> >> and at the same time (before receiving anything from the
>>> >> >> >>> >> client),
>>> >> >> >>> >> the
>>> >> >> >>> >> server
>>> >> >> >>> >> also sends a partial greeting
>>> >> >> >>> >
>>> >> >> >>> >
>>> >> >> >>> >> The server validates the socket type, accepts it, and
>>> replies
>>> >> >> >>> >> with
>>> >> >> >>> >> a
>>> >> >> >>> >> READY
>>> >> >> >>> >> command
>>> >> >> >>> >
>>> >> >> >>> >
>>> >> >> >>> > The partial greeting isn't quite against the word of the spec
>>> >> >> >>> > though
>>> >> >> >>> > it
>>> >> >> >>> > would be good if it was described more clearly in the spec
>>> >> >> >>> > itself,
>>> >> >> >>> > however
>>> >> >> >>> > waiting to send the READY until after validating the client's
>>> >> >> >>> > READY
>>> >> >> >>> > goes
>>> >> >> >>> > directly against the MUST requirement.
>>> >> >> >>> >
>>> >> >> >>> > Am I missing something or does the spec and/or worked example
>>> >> >> >>> > need
>>> >> >> >>> > changing?
>>> >> >> >>> >
>>> >> >> >>> > Regards,
>>> >> >> >>> > Elliot
>>> >> >> >>> >
>>> >> >> >>> >
>>> >> >> >>> > _______________________________________________
>>> >> >> >>> > zeromq-dev mailing list
>>> >> >> >>> > zeromq-dev at lists.zeromq.org
>>> >> >> >>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> >> >> >>> _______________________________________________
>>> >> >> >>> zeromq-dev mailing list
>>> >> >> >>> zeromq-dev at lists.zeromq.org
>>> >> >> >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> _______________________________________________
>>> >> >> >> zeromq-dev mailing list
>>> >> >> >> zeromq-dev at lists.zeromq.org
>>> >> >> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> >> >> _______________________________________________
>>> >> >> zeromq-dev mailing list
>>> >> >> zeromq-dev at lists.zeromq.org
>>> >> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> >> >
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > zeromq-dev mailing list
>>> >> > zeromq-dev at lists.zeromq.org
>>> >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> >> _______________________________________________
>>> >> zeromq-dev mailing list
>>> >> zeromq-dev at lists.zeromq.org
>>> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > zeromq-dev mailing list
>>> > zeromq-dev at lists.zeromq.org
>>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>
> _______________________________________________
> 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/20160524/36db63f6/attachment.htm>


More information about the zeromq-dev mailing list