Intention is to grab some knowledge on below items
- Define message formats in .proto file
- Use the protocol buffer compiler
- Use the C++ Protocol buffer API to write and read messages
With protocol buffers, developer write .proto description of the data structure one wish to store. From that the protocol buffer compiler creates a class that implements automatic encoding and parsing of the protocol buffer data with an efficient binary format. The generated class provides getters and setters for the fields that make up a protocol buffer and take care of the details of reading and writing the protocol buffer as a unit. The protocol buffer format supports the idea of extending the format over time such a way that the code can still read and encode the data with the old format.
The syntax for the protocol buffer is similar to the Java or C++. In protnbuf terms, individual fields are called messages. Message is just an aggregate containing a set of fields. Many standard simple data types are available as field types, including bool, int32, float, double, and string. Tag numbers are used in each field to that is identifier during binary encoding. Tag numbers 1-15 require one less byte to encode than higher numbers, so as an optimization you can decide to use those tags for the commonly used or repeated elements, leaving tags 16 and higher for less-commonly used optional elements. Each element in a repeated field requires re-encoding the tag number, so repeated fields are particularly good candidates for this optimization.
Each field must be annoted with one of the following modifiers
1. required: A value for the field must be provided, otherwise message will be considered as initialised. If protnbuf compiled in debug mode, uninitialised required value if met will result in assertion failure.
2. Optional: This field may or may not be set. IF optional value is not set, default will be used.
3. repeated : the field may be repeated any number of times. The order of repeated values will be preserved in the protocol buffer.
The required is non reversible. this means that if we want to change the field type to non required later, then old messages cannot be read successfully.
Sample message is as below. the protocol buffer message must be saved in a file with .proto extension.
package tutorial;
message Person
{
required string name = 1;
required string 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;
}
message AddressBook
{
repeated Person person = 1;
}
references:
No comments:
Post a Comment