KDB IPC Serialization and endianness tag

Community Support
1

I have a question about IPC and endianness conversion (or lack thereof).

The IPC format specifies an endianness flag which appears as one of the first fields. This flag states the endianness of the machine which was used to serialize the data.

From what I can tell, no conversion is done.

In a typical data serialization process, particularly for data which is to be sent over a network socket, one would expect that hton and ntoh functions would be called to convert from the machine native endianness to big endian, which is typically expected for network communication.

“Big endian” aka “network byte order”.

So here is my question. From what I can tell, KDB will not change the byte order from little endian to big endian on x86 machines. (Which are themselves little endian.)

(Is this correct?)

So, does this mean that if data is read by a machine which has a different byte order to the machine which has written the data that it is up to the reading machine/library to swap the order of the bytes during the reading process?

eg: if I run KDB+ on a little endian machine, and it serializes data for network communication, and that data is read by a big endian machine, whatever software is used on the big endian machine that becomes responsible for swapping bytes.

Thanks

2

It is used to state the endianness of the data in the serialised message. If anything is deserialising the data with a different endianness it will need to alter the data.

3

The endianness of a message is flagged in the header
javakdb/javakdb/src/main/java/com/kx/c.java at master · KxSystems/javakdb

isLittleEndian=rBuff[0]==1;  // endianness of the msg

Then the deserializing logic uses that information to determine which mode to operate.

.e.g

  /**
   * Deserialize long from byte buffer
   * @return Deserialized long
   */
  long rj(){
    int x=ri();
    int y=ri();
    return isLittleEndian?x&0xffffffffL|(long)y<<32:(long)x<<32|y&0xffffffffL;
  }