Fixed32 always uses 4 bytes for the length prefix - this seems to be not uncommon for people who package messages manually (indeed, I even had to add versions with different ends at some point due to repeated requests).
The preference should be Base128, which uses the "varint" encoding, so small numbers take up less space for encoding. In addition, this prefix style can be used to make a sequence of objects wired compatible with a single object with a repeated field, which has several useful applications.
Return the length; if you use DeserializeWithLenghPrefix or DeserializeItems , you do not need to - it processes it internally. But if you need it, check out Serializer.TryReadLengthPrefix .
To clarify: the purpose of *WithLengthPrefix methods is to allow the separation of different objects / messages in one thread - most often: network sockets. This is necessary because the protocol itself otherwise assumes that the entire stream is the only message, so keep reading until the stream / socket is closed.
Re 22 vs 21 bytes; this is because the length prefix itself takes some length :) in fact, if the array is 22, I am a little surprised that the payload is not 20 - the byte header field (to make the composite stream itself a valid protobuff stream), 1 byte long and payload of 20 bytes. I'm on my mobile phone now, so I can’t run the sample for research; however, you can omit the field header (optional), so it can be a length of 1 byte, a payload of 21 bytes. I'll watch it later.