The story of Msgpack and Protobuf (msgpack apparent lack of productivity)

The author used to test Msgpack's keywords and Chinese characters in 2014, so I gave up, this article is a comparison written many years ago, and we've been using HTTP protocols and PROTOBUF.

Look at Msgpack's documentation, claiming to be more efficient than other similar products up to 8 times times, very tempting, right? Come and see my story.

First a lot of projects are cross-language, we are no exception front AS3, back-end C + +, itself I was directed at Msgpack support language, high efficiency, because all know AS3 itself efficiency is very low, if the resolution efficiency must not tragedy, this time I have not started using PROTOBUF, have never used protobuf, at least I deny a lot of developers said to use the protobuf point of view, and then forced them to use Msgpack, and then began a long integration, do not superstition the official third-party libraries, most of them do not update this is the second, The point is that you need to make a lot of changes, we want to allow him to fully support cross-lingual counterpart, AS3 we make a lot of changes, we can barely correspond to some of the content, but there are many things to note, this time the msgpack is still very fragile, at least in the AS3.

Then the first tragedy happened, here in fact, I am more fortunate that he happened in the early stages of the project rather than the late project, according to the rapid development principle, if the cost of development in the middle and late I pay far more than to develop the system itself 3~15 times even more, this tragedy is the Chinese send text truncation, And the truncation of the party is the server side, that is, C + + version by the official provision of the Analytic library, you think I will immediately give up msgpack? You're wrong. Solution, debugging, read msgpack a large number of documents, and finally I found that the GBK text contains a character in the split byte contains 0xce, and this is actually representative of Msgpack UINT32, so it can be imagined here to start truncation, unable to continue analysis, Then the server side crashes.

Unfortunately this is not the biggest problem, and then I did find the solution BASE64, the cost of the solution is that I have to write a layer to deal with the conversion of BASE64, followed by the use of complexity and degrees of freedom apparent difference, the packet slightly increased, this robbery temporarily, and then I found that I need to teach other people how to use Msgpack to package packets.

In the next few days I wrote a simpler combo class, but I found it was still complicated, requiring at least 3 lines to send a msgpack, but at least three rows.

Then the others began to learn to use the Msgpack, when the distance I have just selected Msgpack has been 2 weeks, of course, I think this is a new thing should be like this, the next nightmare came.

The first package Login_syn, we began to coordinate each detail can have a very troublesome problem, SESSION code is INT64, how to correspond to AS3, we test for a long time later still wrote BigInt class, and then complete the corresponding, nightmare more and more.

Until one day, everyone started complaining that it was difficult to write, and when it came to writing a lot of extra protocol classes, I decided to try Protobuf because of team pressure.

And then I was shocked. From the start of the use to direct production, we spent only 4 hours, and this 4 hours we spent most of the time making Protobuf's tools produce AS3 protocol classes.

Our approach is to:

1, find the latest PROTOBUF official source (about 5 minutes, including download time)

2, compile C + + version of Windows tools (about 10-15 minutes, including compile time, full version compilation includes C + + class library)

3, find AS3 generation class and AS3 resolution class put into AS3 project (about 2 hours, download and project integration, modify the underlying time)

4, then compile and integrate the C + + version of the tool (1 hours and 20 minutes, the AS3 generated code into the tool, integration to modify the C + + bottom, and then compile)

5, Next send the first packet (about 30 minutes, write a protocol and generate, do batch processing automatically generated AS3 and C + + Class)

* The above is for someone boring remember, here just to use, he is protobuf advocate faction, not to record time to see how much shorter.

Before and after we had only spent 4 hours, I was using protobuf for the first time, but it was so simple that I was shocked and I never really thought that it would be so easy to write a protocol.

Then I just encapsulated my protocol and AS3 's send class to do docking integration, just 2 lines of code, you can send the full package, and all the writing classes can be generated through the tool integration, the entire development time shortened too much, and almost no teaching, all novice learned how to use PROTOBUF.

See above you know, for the productivity of the problem, the efficiency of the hype is also nonsense, and now recall the use of msgpack production, light write protocol Class I think our costs do not know how much, and we have to re-maintain an HTML protocol document or wiki (easy to read online) , let front-end colleagues understand, otherwise it will be chaos.

Currently we have used PROTOBUF to integrate 40 of packets, including between servers, client servers, etc., we just need a thing called SVN to let the client colleague 100% understand what this protocol is about and what he's dealing with, I have been writing my own agreement is always to explain a lot, but also add a lot of comments, but I now think Protobuf is the king, too fast.

If you are the responsible Director or the responsible boss, please do not let the staff waste time on meaningless things, even pay a huge price, and the low productivity often will drag you to integrate the project and even let you go bankrupt.

In this sense, msgpack actual productivity is not high relative to protobuf, no matter how efficient, in fact, for multi-person coordination projects and cross-language projects he is still a very troublesome thing.

The biggest difference between the two is that Protobuf is born for rapid production, and msgpack is not, so in regular projects with Msgpack and Protobuf is undoubtedly protobuf

Msgpack and Protobuf stories (msgpack apparent lack of productivity)