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

Protobuf messages are associative arrays of key value pairs, where the key
is a union of the field number encoded as a varint and the value wire type
(union operator being a left shift of the field number by 3 bits). Because
the field number is variable width, it's theoretical size is unbounded but
is likely implementation dependent as some programming languages super
arbitrarily large numbers, and other implementations might use fixed width
types to represent the field for convenience.

If you are trying to prevent collisions between two people modifying the
key space, I recommend making separate embedded messages so there is no
chance of collision. CRC-ing field numbers is just too heavy weight for
what it is you're trying to do in my opinion.

Regarding performance, varint encoding/decoding time is O(n) in the byte
length of the result. Whether this is important depends on your application
of course, but you're really better off understanding how the encoding
works so you can do a quick back of the envelope guess to see if it
matters, followed by actually benchmarking if performance is really that
important to you.

On Sun, Jun 19, 2016 at 7:56 AM, a_teammate <mad...@web.de> wrote:

> Hey there,
>
> This might a stupid question, but i haven't found anything certain in the
> docs/specs about that:
>
> Our main goal is actually to keep compatibility while syncing a tree.
>
> The protocol is actually just one giant oneof containing all possible
> paths for the tree:
>
> message TreeNodeChanged {
>
>    oneof key {
>
>       sometype path_to_node1 = 1;
>
>       sometype path_to_node2 = 2;
>
>       ...
>
>     }
>
>  }
>
>
> and thats already working.
> The problem is however that we don't only want forward backward
> compability between server and client, but also sideways:
> e.g. person A introduced message index 2 and also did person B, both
> meaning totally different things, but it should be recognized and
> ignored(/or maybe even accepted?! if we find a way to do this)
>
>
> So the idea of my mate was to make the field number a hash of the
> path_to_node!
> Candidates are e.g. a 32bit FNV-hash or maybe an adapted CRC32. This would
> both mean field numbers in a pretty high area.
>
> Maybe we're going the totally wrong way here but following this path leads
> to the following issues:
>
>
> 1) what is the maximum value of the protobuf field numbers?
>
> In the proto language specification
> <https://developers.google.com/protocol-buffers/docs/reference/proto3-spec#fields>
> it simply says its of type "intLit" and intLit is:
>
> intLit     = decimalLit | octalLit | hexLit
>> decimalLit = ( "1" … "9" ) { decimalDigit }
>> octalLit   = "0" { octalDigit }
>> hexLit     = "0" ( "x" | "X" ) hexDigit { hexDigit }
>>
>>
> So this means only decimal and hexadecimal values are actually allowed
> doesnt it?
> Then however given:
>
> decimalDigit = "0" … "9"
> hexDigit     = "0" … "9" | "A" … "F" | "a" … "f"
>
>  Means it has different limits for hex and int notation, is that correct?
>
> I mean:
>
> the max value for decimalLit is one billion-1 : "999 999 999"
> according to this specs, which fits fine in a 32bit integer (with 30bits
> set)
>
> but for base 16 its allowed length is 16! which would be awesome cause that
> would mean an allowed integer size of  64bit.
>
> So which one is true? Both?
>
> which leads to issue 2:
>
> 1) are there issues with high field numbers
>
> And are they even tested at all?
>
> I've red elsewhere
> <https://developers.google.com/protocol-buffers/docs/proto#customoptions>
> that *"we have used field numbers in the range 50000-99999. This range is
> reserved for internal use within individual organizations"*
> which would suggest that even values above 50 000 are uncommen ..
>
> Furthermore some people mentioned high values would suffer from beeing
> less performant, but: in how far is that relevant? Only because the index
> number consumes slightly more memory?
>
>
> Well: Maybe we totally ask the wrong questions here and theres a much
> simpler logic already introduced or invented to better make protobuf
> message version independent, if yes we would be happy to hear them!
>
> Thanks in advance and for reading all this stuff :)
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to protobuf@googlegroups.com.
> Visit this group at https://groups.google.com/group/protobuf.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Jeremy Ong
PlexChat CTO
650.400.6453

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Reply via email to