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

Pieter Hintjens ph at imatix.com
Mon May 23 14:15:37 CEST 2016


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



More information about the zeromq-dev mailing list