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 <[email protected]> wrote: > > Am 06.06.2013 um 14:09 schrieb Pieter Hintjens <[email protected]>: > >> 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
