[zeromq-dev] ZMTP 1.0 clarification

Merijn Verstraaten merijn at inconsistent.nl
Sat Aug 16 21:50:08 CEST 2014


Hi Pieter,

Yes, I saw that short lengths can still be encoded by a long length value. Some more clarifications:

In ZMTP 3.x how are duplicated metadata fields in the authentication handshake supposed to be handled? Suppose a client sends two Socket-Type fields, or perhaps multiple identity fields. I’m guessing this should be treated as an error and disconnected via an ERROR command?

Also, I see some of the BNF’s using VCHAR, how is VCHAR defined? All printable characters or something else?

Cheers,
Merijn

On 16 Aug 2014, at 00:38 , Pieter Hintjens <ph at imatix.com> wrote:
> Yes, this is safe to say. However note that ZMTP v2 and later use a
> long length, and an empty identity, to handshake with older
> implementations. So while the first frame must be 255 or shorter, that
> length may be encoded in 1+8 bytes (not always 1).
> 
> -Pieter
> 
> On Sat, Aug 16, 2014 at 9:08 AM, Merijn Verstraaten
> <merijn at inconsistent.nl> wrote:
>> Ola!
>> 
>> I’m getting back to my own implementation of ZMTP, I’m trying to be backwards compatible and have a question about the ZMTP1 handshake. The spec states that identities must be between 1 and 255 bytes and the first message in a ZMTP1 connection contains the id. So it’s safe to say that any first message with a length > 255 is an error?
>> 
>> Cheers,
>> Merijn
>> 
>> _______________________________________________
>> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140816/e390b95d/attachment.sig>


More information about the zeromq-dev mailing list