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

[Elliot Crosby-McCullough]

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