Protocol buffers (PROTOBUF) Developer's Guide---overview

Protocol buffers (PROTOBUF) Developer's Guide---overview

welcome here . protocol Buffers's Developer's Guide document, protocol buffers is a programming language agnostic, system platform independent, extensible, structured data serialization/deserialization tool for communication protocols, data storage, and more.

PS: For the convenience of spelling, the following protobuf refers to protocol buffers.

This document is intended for the reader: Java, C + +, Python developers who want to use PROTOBUF. This overview will show you how to get started with protobuf, then you can follow the example and learn more about how PROTOBUF is encoded. The API reference documentation is also available in these three languages, and for better writing. The. Proto file provides language guidance and style guidance documentation.

-------------------------------------------------------------------------------------a small dividing line------------------------------ ----------------------------------------------------------------------------

What is PROTOBUF?

Protobuf is a flexible, efficient, and automated mechanism for structured data sequence tools, similar to XML, but smaller, faster, and simpler than XML. Simply define the data structure once and you can use the code generator to generate structured reads and writes of various programming languages and various streaming files. You can even update new structured data without recompiling the deployment of a new program.

How did they work?

You need to specify the structure of the information you need to serialize in the Protobuf information file (. proto). Each protubuf information is a small logical record that contains a series of "key-value" combinations. Here is an example of a protobuf information file that defines personal information!

Message person {  Required String name = 1;  Required Int32 id = 2;  Optional String email = 3;  Enum Phonetype {    MOBILE = 0;    HOME = 1;    Work = 2;  }  Message PhoneNumber {    Required String number = 1;    Optional Phonetype type = 2 [default = HOME];  }  Repeated PhoneNumber phone = 4;}

As you can see, the information format is simple, each message type has one or more unique fields, each with a name and value type, the type of the value may be a number (integer or floating point), logical value, String, byte, or other custom Protobuf message type ( As the example above Phonenubmer the Phonetype type is a custom PROTOBUF message type), allowing you to use a multi-layered structure, you can specify optional (optional), required (must), repeated (repeat), Need more information about the. Proto documentation help please see the Protobuf language guide

Once you have defined your own message format, you can run the Protobuf compiler to compile your. proto file into a language-specific class. These classes provide a simple way to access each field (like query () and Set_query ()) and serialize or deserialize the structure as if it were a method of accessing a class. For example, you can select the C + + language and run the compiled protocol file to generate a class called person. You can then use this class to serialize the read information in your app. You can write the code this way (this process is called serialization):

PersonPerson;Person.Set_name( "John Doe" ); person.1234. Set_email "[email protected]"  ( "myfile" , iOS ::out | iOS ::binary. Serializetoostreamoutput      

Then you can read the serialized information in this way (this process is called deserialization):

FStream input("MyFile",Ios::Inch |Ios::Binary);PersonPerson;Personparsefromistream (&input<<  "Name:"   << Person. ()  << Endl;< Span class= "PLN" >cout <<  "e-mail:"  Span class= "pun" ><< Person. ()  << Endl  

You can arbitrarily add fields to the data structure without affecting backward compatibility, and the old data ignores the new fields. So if you use PROTOBUF as a communication protocol, you can extend the protocol without worrying about breaking existing code.

Here you can find the complete API Reference API Reference section, about protobuf How to encode the complete document protocol Buffer Encoding here.

Why not use XML?

PROTOBUF has more advanced serialization features than XML:

• More simple
• 3-10 Times smaller
• 20-100 Times faster
• Less ambiguity
• Easy to build data access classes for ease of use

For example, let's look at how to model the name and email fields of person in XML:
[HTML]View Plaincopyprint?

1. <person>
2. <name>john Doe</name>
3. <email>[email protected]</email>
4. </person>

[HTML]View Plaincopyprint?

1. <person>
2. <name>john Doe</name>
3. <email>[email protected]</email>
4. </person>

The corresponding Protocolbuffer message is as follows: This is the text representation of the PROTOBUF
This is not a normal use of binary data
[CPP]View Plaincopyprint?

1. person {
2. Name: "John Doe"
3. Email: "[email protected]"
4. }

[CPP]View Plaincopyprint?

1. person {
2. Name: "John Doe"
3. Email: "[email protected]"
4. }

When this message is encoded into the PROTOBUF binary format (the text above is only used for debugging and editing), it requires only 28 bytes and 100-200ns parsing time. The version of XML requires 69 bytes (except whitespace) and 5000-10000ns parsing time.

Of course, Operation Protobuf is also very simple:
[CPP]View Plaincopyprint?

1. cout << "Name:" << person.name () << Endl;
2. cout << "e-mail:" << person.email () << Endl;

[CPP]View Plaincopyprint?

1. cout << "Name:" << person.name () << Endl;
2. cout << "e-mail:" << person.email () << Endl;

And the XML you need:
[CPP]View Plaincopyprint?

1. cout << "Name:"
2. << person.getelementsbytagname ("name")->item (0)->innertext ()
3. << Endl;
4. cout << "e-mail:"
5. << person.getelementsbytagname ("email")->item (0)->innertext ()
6. << end;

[CPP]View Plaincopyprint?

1. cout << "Name:"
2. << person.getelementsbytagname ("name")->item (0)->innertext ()
3. << Endl;
4. cout << "e-mail:"
5. << person.getelementsbytagname ("email")->item (0)->innertext ()
6. << end;

Of course, PROTOBUF is not always more appropriate than XML, for example PROTOBUF cannot model a document based on tagged text because you simply cannot easily insert a structure into the text. In addition, XML is easy for human to read and edit, while Protobuf is not. and XML is self-explanatory, and protobuf only makes sense when you have a. proto file with the message format definition. feel this solution is very good, very suitable for me, how should I start? Click to download the PROTOBUF package – this contains the Java, Python, C + + protobuf compiler source code, and how to generate the IO class you need. To build and install the Protobuf compiler, consult the Readme documentation. Once you're ready, try to follow the instructions in the language of your choice, which will step you through how to build your application using Protobuf! a little history of ProtobufProtobuf was originally developed at Google to address the request and response protocols of the Index server. Before using Protocolbuffer, there is a format to process the encoding and decoding of request and response data and to support multiple versions of the protocol. And this eventually leads to ugly code, such as:

If (Version== 3) {... } elseif  (version > 4)  {if  (version == 5)   {      ...    }    ...  }             

Communication protocols are therefore becoming more complex because the developer must ensure that the person making the request and the person receiving the request must be compatible at the same time, and that the other party will be able to accept the new agreement when the other party begins to use it.

PROTOBUF is designed to address this type of problem:

• It is convenient to introduce new fields, and intermediate servers can ignore these fields and pass the past without having to understand all the fields.
• Format can be self-descriptive and can be used in multiple languages (c + +, Java, etc.)

However, the user still needs handwriting parsing code.

As the system evolves, he needs some other features:

• Encode and decode code is generated automatically without having to write the parser yourself.
• In addition to short RPC (Remote Procedure Call) requests, people use PROTOBUF to make data storage formats (such as bittable).
• The RPC server interface can be described as a. proto file, while the PROTOBUF compiler generates the access (stub) class for the user to implement the server interface.

Protobuf is now a mixed-language data standard for Google, with more than 48,162 message format definitions and more than 12,183. proto files already in use. They are used for RPC systems and continuous data storage systems.

Original address: Https://developers.google.com/protocol-buffers/docs/overview

Reference translation from: Wolf. exe's blog: http://blog.163.com/jiang_tao_2010/blog/static/12112689020114305013458/

Protocol Buffers (PROTOBUF) Developer's Guide---overview