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

Pieter Hintjens ph at imatix.com
Mon May 23 22:35:45 CEST 2016


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



More information about the zeromq-dev mailing list