Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Endianness of protocol buffer message

Background:

A C++ program run on a server and outputs network data in a protocol buffer file. The data contains, among other things ip addresses and ports.The ip and port are saved as uint32 values in the file. The C++ program is running on a linux server with a intel processor

I have a C# application that reads this file and uses the data for analysis. The C# application runs on a windows 7 machine with a intel processor. I am using Jon Skeet's protobuf-csharp-port for reading protobuf in C#.

When reading the data, I see that the byte order of the ip and port values is big endian and I need to reverse it before using it in my application.

Question:

Does protocol buffer output values in big endian format even though the machine processor is intel (which from what I searched uses the little endian format)?

Is there any way I could force the byte order to be little endian when saving the data to file in order to save processing when reading it?

like image 494
EndlessSpace Avatar asked Mar 06 '15 18:03

EndlessSpace


2 Answers

If you are using a Protocol Buffers library (not trying to encode it yourself), you should never actually see or care about the endianness that Protobufs itself uses. The library will convert to your native endianness automatically. So if a value comes out backwards, it's because it was inserted backwards in the first place.

With that said, the endianness of the Protobuf encoding can be said to be little-endian, although it's somewhat more complicated. Most integers are encoded in "varint" encoding, not fixed-width. Technically this encoding does encode low-order bits first, but it's not what people usually think of when they say "little-endian integer".

like image 106
Kenton Varda Avatar answered Oct 03 '22 14:10

Kenton Varda


Protocol buffers messages always use little-endian encoding. Implementations running on big-endian architectures should be doing the conversions automatically.

If you are receiving data in wrong order, I would suggest using protoc --decode_raw to see whether the error occurs on the transmission or reception side.

like image 28
jpa Avatar answered Oct 03 '22 13:10

jpa