Currently the on-the-wire format is endianness agnositc.
Meaning, we don't know what byte ordering is used to represent multi-byte entities (like integers).
This is fine as long as we don't want to communicate between processes on different machines/architectures/...
Changing this is in principle a brealing change that creates a new wire-format version. If we know who our users are, we could try to make the preferred wire format the same as it was in the majority of use-cases.
Implementation note: I'd suggest using the corresponding types from Boost Endian
using wire_u16 = boost::endian::big_uint16_t;
struct headers_t {
wire_u16 topiclen;
wire_u16 bodylen;
action msgaction;
wire_u16 magic;
};
Currently the on-the-wire format is endianness agnositc.
Meaning, we don't know what byte ordering is used to represent multi-byte entities (like integers).
This is fine as long as we don't want to communicate between processes on different machines/architectures/...
Changing this is in principle a brealing change that creates a new wire-format version. If we know who our users are, we could try to make the preferred wire format the same as it was in the majority of use-cases.
Implementation note: I'd suggest using the corresponding types from Boost Endian