What are protocol buffers?Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages. You can even update your data structure without breaking deployed programs that are compiled against the "old" format. How do they work?You specify how you want the information you're serializing to be structured by defining protocol buffer message types in message Person { As you can see, the message format is simple – each message type has
one or more uniquely numbered fields, and each field has a name and a
value type, where value types can be numbers (integer or
floating-point), booleans, strings, raw bytes, or even (as in the
example above) other protocol buffer message types, allowing you to
structure your data hierarchically. You can specify optional fields,
required fields, and repeated fields. You can find more information
about writing Once you've defined your messages, you run the protocol buffer compiler for your application's language on your Person person; Then, later on, you could read your message back in: fstream input("myfile", ios::in | ios::binary); You can add new fields to your message formats without breaking backwards-compatibility; old binaries simply ignore the new field when parsing. So if you have a communications protocol that uses protocol buffers as its data format, you can extend your protocol without having to worry about breaking existing code. You'll find a complete reference for using generated protocol buffer code in the API Reference section, and you can find out more about how protocol buffer messages are encoded in Protocol Buffer Encoding. Why not just use XML?Protocol buffers have many advantages over XML for serializing structured data. Protocol buffers:
For example, let's say you want to model a <person> while the corresponding protocol buffer message (in protocol buffer text format) is: # Textual representation of a protocol buffer. When this message is encoded to the protocol buffer binary format (the text format above is just a convenient human-readable representation for debugging and editing), it would probably be 28 bytes long and take around 100-200 nanoseconds to parse. The XML version is at least 69 bytes if you remove whitespace, and would take around 5,000-10,000 nanoseconds to parse. Also, manipulating a protocol buffer is much easier: cout << "Name: " << person.name() << endl; Whereas with XML you would have to do something like: cout << "Name: " However, protocol buffers are not always a better solution than XML
– for instance, protocol buffers would not be a good way to model a
text-based document with markup (e.g. HTML), since you cannot easily
interleave structure with text. In addition, XML is human-readable and
human-editable; protocol buffers, at least in their native format, are
not. XML is also – to some extent – self-describing. A protocol buffer
is only meaningful if you have the message definition (the Sounds like the solution for me! How do I get started?Download the package – this contains the complete source code for the Java, Python, and C++ protocol buffer compilers, as well as the classes you need for I/O and testing. To build and install your compiler, follow the instructions in the README. Once you're all set, try following the tutorial for your chosen language – this will step you through creating a simple application that uses protocol buffers. A bit of historyProtocol buffers were initially developed at Google to deal with an index server request/response protocol. Prior to protocol buffers, there was a format for requests and responses that used hand marshalling/unmarshalling of requests and responses, and that supported a number of versions of the protocol. This resulted in some very ugly code, like: if (version == 3) { Explicitly formatted protocols also complicated the rollout of new protocol versions, because developers had to make sure that all servers between the originator of the request and the actual server handling the request understood the new protocol before they could flip a switch to start using the new protocol. Protocol buffers were designed to solve many of these problems:
However, users still needed to hand-write their own parsing code. As the system evolved, it acquired a number of other features and uses:
Protocol buffers are now Google's lingua franca for data – at time of writing, there are 48,162 different message types defined in the Google code tree across 12,183 |