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

Pieter Hintjens ph at imatix.com
Tue May 24 07:34:24 CEST 2016


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160524/bf1f1f20/attachment.htm>


More information about the zeromq-dev mailing list