Use Protocol Buffer instead?

[FICTURE7]

I was surfing the web and came across Protocol Buffer and Its kinda similar to what we're doing here.

[clugh]

Unless I'm missing a method to change it, the buffer format is wildly different from the client's. For example, the individual fields appear to be separated by 0x10 and array elements by 0x0a. There are some similarities, such as strings are prefixed with their length, but arrays don't appear to be.

Do you see a way to alter this?

Edit: I would definitely be interested in using something like this, assuming we can make it work.

[FICTURE7]

Hmmm, silly me, I expected them to allow us to write our own encoding as well. One way would be to hack it to use our own encoding but that would probably require a lot of work and its very likely that its gonna break something.

[FICTURE7]

In the C# version of it you can use the Descriptor to figure out fields of a message and using that we could write our encoding.

[clugh]

I don't see the value in using it simply as a definition format. If we'll still have to use our own code to pack and unpack the messages, that's all this would really be.

If we could replace all of the logic to handle packing and unpacking the messages with some standardized script like this, where we only have to provide the message definitions (and maybe some config settings), and it does the rest, then I could definitely see the benefit.

[FICTURE7]

Hmmm, thats true. I am a moron, there is no point of using it as a definition format and its main advantage is that it can turn definitions into source code but unfortunately cannot use our own encoding without having to hack it or a side script.

I think that sticking with the current definition format and improving it is the way to go, it should not be that hard do the same thing with our own implementations. Furthermore we could be generating wiki pages easily. You can close the "issue" if you feel like idea is sort of pointless.

[clugh]

I really like the idea of using something like this, but, unfortunately, the output format is incompatible and there doesn't appear to be any way to configure it.

I'll close it for now, but if you come across an alternative, I'm certainly open to suggestions.

[ghost]

Putting this information into a format known as ProtoDef could be of great use https://github.com/roblabla/ProtoDef although it is JavaScript specific, it could be used for other languages that follow the same semi-standardized format. That way, we don't have to index the entire repository for each individual .json file.

[clugh]

I'm not following this line:

That way, we don't have to index the entire repository for each individual .json file.

Can you elaborate?

The appeal of Protocol Buffers was that it was widely used and supported several programming languages, with each being well maintained. I suppose it is possible to offload the decoding to node.js, but I would much rather keep the dependencies to to a minimum. Another possibility would be to port ProtoDef to other languages, but I personally have no interest in maintaining it.

[ghost]

I believe an idea of ProtoDef is in the works for python. The only issue with protocol buffers is that types cannot be defined that may be used by Clash of Clans. As far as the protocol.json file goes, I believe it is much more efficient to have an entire protocol file contained in itself, ex. https://github.com/PrismarineJS/minecraft-data/blob/master/data/0.30c/protocol.json (that is protocol information for the video game minecraft-classic)

[clugh]

Keeping the definitions in a single file or separate is just a matter of personal preference. If I had done it myself from scratch, I probably would have put them in a single file (or at least used the message IDs for file names). In my proxy, I compensate by iterating through them all and restructuring the data to my preferences in memory when the app starts. As for efficiency, the overhead is nearly nonexistent (6ms to read the files and 3kb to store the relevant information in memory).

The real advantage of something like this is really just to make adoption easier for other projects, since the main goal here is to increase adoption, so there are more people maintaining the definitions, so we're not all duplicating work. It would be great it we could take that a step further so we're not all writing code to decode packets using the definitions, but that is secondary to the definitions themselves.