Am Montag, 20. Juni 2016 20:50:17 UTC+2 schrieb Jeremy Ong:

> 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.
>

Ah! thank you for pointing that out, that lets me understand the structure 
of protobuf much better, and especially thanks for the link!

Am Montag, 20. Juni 2016 21:47:39 UTC+2 schrieb Feng Xiao:
>
>
> On Sun, Jun 19, 2016 at 7:56 AM, a_teammate <mad...@web.de> wrote:
>>
>> 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)
>>
> If person A already added a field with field number 2, how can person B 
> add another one with the same field number? Do you have multiple copies of 
> the .proto files and they are not synced?
>

Well we're an open-source multiplayer-game and highly encourage modding: So 
it would be cool if a modded client meeting a modded server could work 
together (could be doable since our scripting uses a similar/the same API, 
if that's smart security-wise is another question ofc)
The protobuf code gets generated here from code reflection, so people don't 
need to deal with syncing themselves. That's where I meant would the CRCing 
would come into play,
well I assume I wasn't quite clear about that initially.

 Am Montag, 20. Juni 2016 20:50:17 UTC+2 schrieb Jeremy Ong:

> 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.
>

Separate embedded messages would involve switches for the code generation 
(official build vs modded build) but could be doable, and maybe it is even 
a bit cleaner.
The CRC thing would have meant an uniform solution, but maybe namespacing 
the modded messages isn't the worst idea.
 
Another alternative would be to sync the metadata initially (so the modded 
server deals with the input according to the clients description of its own 
protocol, not on the servers assumption), well we've got the choice :)

Am Montag, 20. Juni 2016 20:50:17 UTC+2 schrieb Jeremy Ong:

> 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.
>
>  
Yeah I see, well benchmarking will come into play sooner or later thats for 
sure!

Am Montag, 20. Juni 2016 21:47:39 UTC+2 schrieb Feng Xiao:
>
>
>
> On Sun, Jun 19, 2016 at 7:56 AM, a_teammate <mad...@web.de> wrote:
>
>> 1) what is the maximum value of the protobuf field numbers?
>>
> The range of valid field numbers is 1 to 2^29 - 1:
> https://developers.google.com/protocol-buffers/docs/proto#assigning-tags
>
> Some field numbers in this range are reserved so you will need to account 
> for those as well. 
>

Ah nice! so if our benchmarks suggests a negligible performane impact, 
hashing could be doable, since that area seems perfectly fine for that.

-- 
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