Hi everybody,
I am having an endianess problem when using Juce InterprocessConnection to communicate with a third-party client written in Python.
When I send a uint32 encoded in big-endian (the network standard) over TCP to a juce server from a Python script, the juce server running on an i386 (little endian CPU) fails to properly decode the packet header because the bytes of the magic number and the packet size are reversed.
The readNextMessage and sendMessage methods of the InterprocessConnection class use ByteOrder::swapIfBigEndian. The later swaps the byte order if the CPU is big-endian as documented.
Bytes order in network transmissions is defined to be big endian in IETF RFC 1700. Thus, most implementation follow this definition. Like the “!” network dedicated format specifier in pack/unpack function, or the ntohs and friends function in the libc.
It works if I patch my script to send little endian data, or if I patch Juce to use swapIfLittleEndian.
IMHO, Juce should instead use swapIfLittle (when running on a big endian CPU there is no need to swap), because right now one cannot design a protocol following network standard and communicate with a server coded with juce.
Cheers,
Nicolas