|Anonymous | Login | Signup for a new account||2020-01-25 02:18 UTC|
|My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001694||Zandronum||[All Projects] Suggestion||public||2014-02-05 02:07||2014-10-13 20:35|
|Target Version||Fixed in Version|
|Summary||0001694: Protocol Buffers for network traffic|
|Description||I would like to propose using Protocol Buffers for future versions of Zandronum’s message serialization.|
- The current method of serializing and unserializing message is very error prone. If your serialization and deserialization functions do not do the exact opposite of each other on either side of the communication, bugs will be introduced, sometimes difficult to track down ones. Protocol buffers fix this by allowing us to define our messages in schema files. When we compile the project, the protoc compiler takes the schemas and writes serialization and deserialization functionality for you automatically.
- The current method of serializing and unserializing messages makes writing a netcode parser in another language a gargantuan task. This makes writing things like demo parsers in non-C++ languages nearly impossible. Protocol buffers trivializes this, there are programs that can dump serializers and deserializers in dozens of languages.
- The current method of serializing and unserializing messages makes no allowances for backwards-compatibility. Backwards compatibility must be done by hand on a per-message basis. Mostly useless for network play, but absolutely vital for netdemo backwards compatibility. Protocol buffer message fields are individually tagged by a number and optional messages can be left out of a message completely with no consequence, or skipped over by the parsing function completely if not desired.
- Messages serialized using Protocol Buffers have a little more overhead in some cases and less in others. The numeric tags for fields are transmitted over the wire, and there is at least a one-byte overhead for each field, two for any field with a tag greater than 15, and three for any tag greater than 2047. On the other hand, numeric fields are very flexible when it comes to ways you can encode them. Fixed-width 32-bit and 64-bit wire representations are offered, but variant encoding is possible for numbers that are generally expected to be close to 0, and zig-zag encoding is possible for numbers that are expected to be negative. Protobuf handles the details of this automatically.
- Integrating it with the Zandronum build systems may be kind of a pain. It’s well trodden ground, since Protocol Buffers is a reasonably popular library by Google, but you have to use protoc to compile the schemas to the target .cpp files.
edited on: 2014-10-13 20:35
Doing this will make it much easier to implement stuff like in my post:
Since we won't need to even care about packets that aren't ours (they will get transmitted nevertheless)
|Only registered users can voice their support. Click here to register, or here to log in.|
|Supporters:||ZzZombo Sonter AlienOverlord|
|Opponents:||No one explicitly opposes this issue yet.|
|2014-02-05 02:07||AlexMax||New Issue|
|2014-04-10 19:08||Dusk||Relationship added||related to 0001777|
|2014-05-04 02:16||Dusk||Relationship deleted||related to 0001777|
|2014-06-15 16:14||Watermelon||Status||new => acknowledged|
|2014-10-13 20:35||AlienOverlord||Note Added: 0010575|
|2014-10-13 20:35||AlienOverlord||Note Edited: 0010575||View Revisions|
Questions or other issues? Contact Us.
|Copyright © 2000 - 2020 MantisBT Team|