[zeromq-dev] Topics for ZMTP 3.0

Pieter Hintjens ph at imatix.com
Tue Jun 11 14:25:30 CEST 2013


The wire format is changing only in places where it needs to (security
mechanisms). There's no reason for radical changes and that would make
it harder for older implementations to catch up.

There are no "fields" to order or serialize, so those concerns don't
apply. Message frames use the same format as before.

-Pieter

On Tue, Jun 11, 2013 at 1:02 PM, Michael Haberler <mail17 at mah.priv.at> wrote:
>
> Am 06.06.2013 um 14:09 schrieb Pieter Hintjens <ph at imatix.com>:
>
>> Hi all,
>>
>> As you may know we're drafting a new protocol for tcp://.
>>
>
> I read this as 'wireformat will change'
>
> In the remote case a more radical departure from the existing wireformat is conceivable, I would suggest:
>
> - consider a type/length/value self-identifying format as used in many IETF protocols, alternatively protobuf encoding
> - stick to normal worst case alignment rules (like an 8-byte length field better start at an address % 8 == 0)
> - order fields in timed processing requirements (see for instance the experiences with IPv4 which went into IPv6, so you can do overlapped processing and reads). This might become relevant some day once you bring this down into hardware and concurrent processing as bits are shifted in. It doesnt cost much now.
>
> - Michael
> _______________________________________________
> 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