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

Pieter Hintjens ph at imatix.com
Mon May 23 14:11:05 CEST 2016


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