Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Protocol Buffers

60 views

Published on

Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data, it's used due to its simplicity and performance. It supports many languages and can be used with scala using Scala PB.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Protocol Buffers

  1. 1. Protocol Buffers
  2. 2. AGENDA ❖ Introduction ❖ Protobuf VS XML ❖ How it works? ❖ Generating Scala Code Using ScalaPB ❖ Backward Compatibility ❖ Important points to remember ❖ Demo
  3. 3. Introduction Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data, and its - ❖ Language-neutral ❖ Platform-neutral ❖ Extensible
  4. 4. Why Protobufs? ❖ Backward Compatibility ❖ Efficient encoding ❖ Better Performance ❖ Strongly typed ❖ Automatically generated parsing code
  5. 5. VS
  6. 6. <person> <name>John Doe</name> <email>jdoe@example.com</email> </person> Its 69 bytes and takes 5­10'000ns to parse Person { name: "John Doe" email: "jdoe@example.com" } Its 28 bytes and takes 100­200ns to parse XML Protobuf
  7. 7. Advantages ❖ are simpler ❖ are 3 to 10 times smaller ❖ are 20 to 100 times faster ❖ generate data access classes that are easier to use programmatically
  8. 8. Disadvantages ❖ XML is human­readable and human­editable whereas protobufs are not ❖ XML is self describing, where as a protocol buffer is only meaningful if you have the message definition
  9. 9. How It Works? ❖ Define your structured data format in a descriptor file (.proto file) ❖ Run the protocol buffer compiler for your application's language on your .proto file to generate data access classes. ❖ Data Access Classes provide ➢ simple accessors for each field (like name() and set_name()) ➢ methods to serialize/parse the whole structure to/from raw bytes
  10. 10. person.proto protoc person.java
  11. 11. 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; } repeated PhoneNumber phone = 4; } Sample proto file
  12. 12. Message Defines a message format/class ❖ Simple syntax for defining message ❖ Fields in a message class must be identified via a numeric index ❖ Field have a name, type and descriptor such as it’s a required field or not ❖ Messages can import or subclass other messages message PhoneNumber { required string number = 1; optional PhoneType type = 2; }
  13. 13. Field Field is represented by <field-type, data-type, field-name, encoding-value, [default value]> Data-types ❖ Primitive data-type ❖ Enumerated data-type ❖ Nested Message - Allows structuring data into an hierarchy required string name = 1;
  14. 14. Continue.. Field-types ❖ Required fields ❖ Optional fields ❖ Repeated fields - Dynamically sized array Encoding-value A unique number (=1,=2,…) represents a tag that a particular field has in the binary encoding of the message
  15. 15. Generating Scala Code Using ScalaPB ScalaPB is a protocol buffer compiler (protoc) plugin for Scala. It will generate Scala case classes, parsers and serializers for your protocol buffers. To generate Scala code, invoke ScalaPBC like this: ./bin/scalapbc -v351 --scala_out=some/output/directory myproto.proto Note: Its recommended to install it in SBT
  16. 16. Backward Compatibility ❖ Do not change the numbered tags for the fields in the messages. This will break the design considerations meant for backward and forward compatibility. ❖ Adding fields is always a safe option as long as you manage them and don’t end up with too many of them. ❖ Add new fields for newer implementations and depreciate older fields in a timely way.
  17. 17. Important Points To Remember ❖ Always remember that backward and forward compatibility is goal #1 with protobuf ❖ Be absolutely sure about a field's long­term necessity when using required ❖ Choose id numbers 1­ to 15 for often used values (more efficiently encoded) ❖ Choose appropriate data types, based on expected values signed/unsigned/generic may result in better encoding
  18. 18. References ● https://developers.google.com/protocol­buffers/docs/overview ● https://www.slideshare.net/xzibitpnp/protocol­bufferppt ● https://www.slideshare.net/fabricioepa/protocol­buffers­44187777
  19. 19. Thank you !!

×