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

Elliot Crosby-McCullough elliot.cm at gmail.com
Mon May 23 19:34:56 CEST 2016


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


More information about the zeromq-dev mailing list