Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Protocol Buffers

77 vues

Publié le

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.

Publié dans : Logiciels
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

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 !!