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

Elliot Crosby-McCullough elliot.cm at gmail.com
Mon May 23 23:11:24 CEST 2016


👍🏻

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


More information about the zeromq-dev mailing list