Each message will contain the following structure:
[ID 16 BITS][Update type 3 BITS][Object Type 13 BITS][Payload N BYTES]
Update types:
000 Action
010 Delete
011 Create
100 Sync Always
101 Sync Sometimes
110 Sync Changed
Payload length will not be specified by the message. Instead, size will be determined by the data contract. Strings will obviously be the exception, since their size will be variable.
Strings will be 8-bit encoded, and 00000000-terminated. Invalid messages and messages that are too long will be thrown out and the client will be disconnected. Subsequent bad messages will result in bans.
First of all, this is a duplicate of #961. Second, this design is 100% flawed. I've come up with a much better way of doing it. See readme.md for more info.
Probably the king of all network optimizations
Each message will contain the following structure:
[ID 16 BITS][Update type 3 BITS][Object Type 13 BITS][Payload N BYTES]
Update types:
Payload length will not be specified by the message. Instead, size will be determined by the data contract. Strings will obviously be the exception, since their size will be variable.
Strings will be 8-bit encoded, and 00000000-terminated. Invalid messages and messages that are too long will be thrown out and the client will be disconnected. Subsequent bad messages will result in bans.