Byte order neutrality

[jacopodl]

Hi, in this PR I removed Uint32Array and replaced it with DataView.

Unfortunately Uint32Array serializes and deserializes data using the byte order of your platform. If the platform sending/receiving the data differs in byte order, the data cannot be read/written correctly.

DataView (in this case) will always and only use the big endian order, guaranteeing compatibility on the various platforms.

[allevo]

Hi!
Thanks for your contribution. Anyway, this PR introduce a 5% of performance penalty.
I'm ok to support this feature differently, for instance adapt the implementation based on the endness.
So if the server returns a content type with this information, the client can adapt the byte interpretation accordingly. So, I support we can enhance seqproto during the deserialization phase where I can pass the type of the endness.
If the client has the same configuration, it is ok the deserialize it directly, otherwise we can use the "slow" implementation with DataView.
In this way, there's not pay any penalties if the the client and the server agree (the case is the server side).

WDYT?

[jacopodl]

Hi!

It's an interesting idea, but handling endianness manually might not be practical. Instead, we could consider adding a "magic_number" to determine the endianness. One possible solution could be initializing "seqproto" using the first incoming bytes (the "magic_number") to determine how to proceed.

We could follow this approach:

• When the first serialization function is called (regardless of which one it is, e.g.: serializeNumber, serializeUInt32), the "magic_number" is added before the serialized data. Subsequently, the next call to the serialization functions continues as usual.
• For the deserializer: the first called function expects to find the "magic_number" as the first thing with which to initialize "seqproto". It then proceeds with deserializing the data as usual.

WDYT?

[allevo]

If we go in this direction, it is a breaking change. While we can change the method signatures, I prefer to keep the dump created compatible (i.e., allow the developer to turn off this option).
So, we can use a createSer and createDes parameter to specify if the dump should contain that initial byte.
createSer({ something: true }) and createDes({ something: true }).
WDYT?