key/tag encoding when message types > 31

[emaz...@cisco.com]

Hello...

I appreciate the clear documentation on encoding here:

https://developers.google.com/protocol-buffers/docs/encoding

However it doesn't discuss how the key/tag is encoded when the number of message types exceeds 5 bits (31).

Each key in the streamed message is a varint with the value (field_number << 3) | wire_type – in other words, the last three bits of the number store the wire type.

What happens if the message type is 76 for example? That is 0x4c. If the data encoding is 000 for a varint then this is just  0x0260. Is that how it is represented in the data stream? Or is it encoded like a varint which I *think* is 0xe004?

Appreciate any information on this.

Thanks,

Ed Mazurek

[Marc Gravell]

The composed wire-type and field number are treated as a varint. And since the MSB is reserved for continuation, after the 3-bit wire type that only leaves 4 bits of field number, not 5, for single-byte field headers.

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/protobuf/0f270391-fe31-4d0d-a736-874c0520a147n%40googlegroups.com.

[emaz...@cisco.com]

Hi Marc,

OK thanks. 4 bits... Right. So for 76 it would look like 0xe004 in a wireshark trace ?

Thanks,

Ed

[Marc Gravell]

Field number 76 with which wire type? The lowest 3 bits are the wire-type, then the field number is whacked on the end. Then split into groups of 7 bits for varint encoding.

To view this discussion on the web visit https://groups.google.com/d/msgid/protobuf/ed75a2d3-655f-4961-a9b8-1ad20900fa9cn%40googlegroups.com.

[emaz...@cisco.com]

Ok yes... varint wire type so the 0x4c is 0x260. then it turns into 0xe004.

Thanks,

Ed