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

Pieter Hintjens ph at imatix.com
Mon May 23 19:20:36 CEST 2016


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



More information about the zeromq-dev mailing list