Bug Tracker – Bug 803

Better message serialization

Last modified: 2012-03-18 21:46:02 CDT
Bug 803 - (ARRAY(0x5ccb3e8)) Better message serialization
Better message serialization
Status: NEW
Product: Odamex
Classification: Unclassified
Component: Server & Client
(old) 0.6-dev
All All
: P1 normal
Depends on:
  Show dependency tree
Reported: 2012-03-18 21:46:02 CDT by Alexander Mayfield
Modified: 2012-03-18 21:46 CDT (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Mayfield 2012-03-18 21:46:02 CDT
Right now, Odamex uses ReadType and WriteType functions for serializing and deserializing packets.  Needless to say, this can be _very_ error prone and has doubtlessly bitten anyone who has done development work on Odamex several times.

To this end, I suggest replacing the ReadType and WriteType functions with some sort of message serialization and unserialization.  Instead of endless strings of WriteType and ReadType, each message should be its own self-contained object that you set values to on one end, serialize, send over the wire, and then get an automatically unserialized object on the other end.

For example, instead of:

MSG_WriteString("This is my message!");
MSG_WriteString("This is my second message!");

...and then reading that exact sequence on the other end, you could:

msg = new MyMessage();
msg->set_string_param("This is my message!");
msg->set_string_param2("This is second message!");

And then on the other end:

std::string string_param msg->get_string_param();
std::string string_param2 = msg->get_string_param2();
short short_param = msg->short_param();

Odamex could possibly roll its own serialization format, but I think it would be worthwhile to investigate other existing serialization formats that are out there, such as Protocol Buffers, Bencoding, MessagePack, and others.  Of these, I would strongly suggest looking at protocol buffers due to the fact that it offers built-in strongly typed messages through declarative .proto files, which I feel is a much better option than rolling our own message verification scheme on top of something else (or worse, simply hoping that the serialized message has everything we need as we grab its data and bailing out of we don't find it).