[Cbor] Handling Endianness with CBOR Tagged Arrays

[Laurence Lundblade <[e-mail]>]

Was thinking about how to ensure interoperability with tagged arrays given the divergence from requiring network byte order. I came up with this text that might go into some document.

LL


Handling Endianness with CBOR Tagged Arrays

Every CBOR protocol using tagged arrays must specify how endianness is handled or there will be interoperability problems. The following are five options, that last of which is not recommended.

1) Default to little-endian
By not specifying anything, the default of little-endian is taken.

This is a pretty good option for many protocols as such a large proportion of CPUs today are little-endian.

2) Specify the endianness
Here the protocol explicitly defines whether big or little endian is to be used. This is a static definition for every implementation of the protocol and it is incorrect to use other than what is defined.

This is only necessary when big-endian is the only endianness allowed. Given how few CPUs support big endian, use of this is likely to be rare as it will force the performance and likely memory penalty on the CPUs the are little-endian.

3) Asymmetric 
Here one side of the protocol, typically the constrained side, sends whatever it wants. It tells the other side what it is going to send and receive. The other side, typically the server, must be able to receive and send both big and little-endian.

The constrained side can tell the server side by something explicit in the protocol, or if the flow of the protocol has the constrained side sending the first message with a tagged array, that can be the indicator.

This is the best option to accommodate constrained devices and keep code size down.

4) Step-up
Both sides are required to implement a base endianness specified by the particular CBOR protocol. Then, there is a negotiation to step up to a preferred endianness if both support it and prefer it. 

This is may not keep code size down, but it can enhance performance as endian conversion can be avoided. It may also reduce memory use, especially on CPUs that can performed unaligned access. The arrays can be read and written directly from memory to the network.

5) Negotiation
One side of the protocol can send a list of which endianness it supports. The other side picks the one in the list it prefers and tells the first side. Note that this can fail to interop and is not recommended.

Basically, both sides have to agree to implement one specific endianness, or one side has to agree to implement both. Interop can fail if both sides just do what they want.