0001694: Protocol Buffers for network traffic

Chat on our Discord Server Get the latest version: 3.1
Source Code

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0001694

Zandronum

[All Projects] Suggestion

public

2014-02-05 02:07

2014-10-13 20:35

Reporter

AlexMax

Assigned To

Priority

normal

Severity

feature

Reproducibility

N/A

Status

acknowledged

Resolution

open

Platform

OS Version

Product Version

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.

WHY?

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

POTENTIAL ISSUES

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

Attached Files

Relationships

Notes
(0010575) AlienOverlord (reporter) 2014-10-13 20:35 edited on: 2014-10-13 20:35	Doing this will make it much easier to implement stuff like in my post: 'http://zandronum.com/forum/showthread.php?tid=5179&pid=70573#pid70573 [^]' Since we won't need to even care about packets that aren't ours (they will get transmitted nevertheless)

**Issue Community Support**
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.

Issue History
Date Modified	Username	Field	Change
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.

Links

Doom and Doom II are the property of id Software.