Protocol Buffers (protobuf) in IOT Protocols - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the output of the protobuf compiler command?

You run the command protoc --python_out=. sensor.proto in your terminal. What is the expected result?

A Generates a Python file named <code>sensor_pb2.py</code> in the current directory.

B Generates a binary executable named <code>sensor</code> in the current directory.

C Outputs the compiled protobuf schema as JSON to the terminal.

D Throws an error because <code>--python_out</code> is not a valid option.

💡 Hint

Think about what the --python_out flag does in the protoc command.

The protoc compiler with the --python_out=. option generates Python code from the .proto file and saves it in the current directory. The output file is named by appending _pb2.py to the proto filename.

🧠 Conceptual

intermediate

What does the 'optional' keyword mean in a protobuf message?

In a protobuf message definition, what does marking a field as optional imply?

A The field must always be set; otherwise, the message is invalid.

B The field is deprecated and should not be used anymore.

C The field may or may not be set; if not set, it uses a default value.

D The field is repeated multiple times in the message.

💡 Hint

Think about what 'optional' means in everyday choices.

Marking a field as optional means it can be left unset. If unset, the field takes a default value (like zero for numbers or empty string for text).

❓ Configuration

advanced

How to define a repeated field in a protobuf message?

You want to define a protobuf message that holds multiple sensor readings in a list. Which of the following message definitions correctly uses a repeated field?

A message SensorData { repeated int32 readings = 1; }

B message SensorData { optional int32 readings = 1; }

C message SensorData { int32[] readings = 1; }

D message SensorData { map<int32, int32> readings = 1; }

💡 Hint

Think about how to say 'many' in protobuf syntax.

The repeated keyword defines a list of values of the specified type. Option A correctly uses repeated int32 readings = 1; to hold multiple integers.

❓ Troubleshoot

advanced

Why does this protobuf message cause a compilation error?

Given this protobuf message definition:

message Device {
  int32 id = 1;
  string name = 1;
}

Why does compiling this cause an error?

IOT Protocols

message Device {
  int32 id = 1;
  string name = 1;
}

A The 'string' type is not supported in protobuf.

B Field names cannot be 'id' or 'name' in protobuf messages.

C The message must have at least three fields to compile.

D Field numbers must be unique; both fields use number 1 causing a conflict.

💡 Hint

Check the numbers after the equals sign for each field.

Each field in a protobuf message must have a unique number. Here, both id and name use number 1, which causes a compilation error.

✅ Best Practice

expert

Which practice helps maintain backward compatibility in protobuf schemas?

You want to update a protobuf message without breaking existing clients. Which practice below best supports backward compatibility?

A Change the type of existing fields to the new desired type directly.

B Add new fields with new unique numbers and mark old fields as deprecated instead of removing them.

C Reuse field numbers for new fields after removing old ones.

D Remove old fields and renumber all fields to keep numbers sequential.

💡 Hint

Think about how to keep old data working while adding new features.

Adding new fields with new unique numbers and deprecating old fields keeps old clients working and supports new features. Changing types or reusing numbers breaks compatibility.

Practice

1. What is the main purpose of Protocol Buffers (protobuf) in IoT devices?

easy

A. To create graphical user interfaces for IoT devices

B. To organize data into small, typed messages for fast communication

C. To store large video files on IoT devices

D. To replace the operating system on IoT devices

Solution

1. Step 1: Understand Protocol Buffers' role

   Protocol Buffers organize data into messages with typed fields, making data small and fast to send.

2. Step 2: Match purpose to options

   Only To organize data into small, typed messages for fast communication describes organizing data into small, typed messages for fast communication.

3. Final Answer:

   To organize data into small, typed messages for fast communication -> Option B

4. Quick Check:

   Purpose of protobuf = Organize data small and fast [OK]

Hint: Remember protobuf is for small, typed data messages [OK]

Common Mistakes:

• Confusing protobuf with UI tools
• Thinking protobuf stores large files
• Assuming protobuf replaces OS

2. Which of the following is the correct syntax to define a simple protobuf message with an integer field named id?

easy

A. message Device { int32 id = 1; }

B. message Device { int id = 1 }

C. message Device { integer id = 1; }

D. message Device { id int32 = 1; }

Solution

1. Step 1: Recall protobuf field syntax

   Protobuf fields use type name, field name, equals sign, and field number ending with semicolon.

2. Step 2: Check each option

   message Device { int32 id = 1; } matches correct syntax: int32 id = 1;. Others have syntax errors or wrong keywords.

3. Final Answer:

   message Device { int32 id = 1; } -> Option A

4. Quick Check:

   Correct protobuf field syntax = message Device { int32 id = 1; } [OK]

Hint: Field syntax: type name = number; ends with semicolon [OK]

Common Mistakes:

• Omitting semicolon at line end
• Using 'int' instead of 'int32'
• Wrong order of field name and type

3. Given this protobuf message definition:

message SensorData {
  string name = 1;
  int32 value = 2;
}

What will be the output type when you decode a protobuf binary of this message in Python?

medium

A. A Python dict with keys 'name' and 'value'

B. A list containing 'name' and 'value' values

C. A string containing the raw binary data

D. An object with attributes 'name' and 'value'

Solution

1. Step 1: Understand protobuf decoding in Python

   Protobuf generates classes; decoding returns an object with fields as attributes.

2. Step 2: Match output type

   Decoded message is an object with attributes 'name' and 'value', not dict or list.

3. Final Answer:

   An object with attributes 'name' and 'value' -> Option D

4. Quick Check:

   Protobuf decode output = Object with attributes [OK]

Hint: Decoded protobuf = object with fields as attributes [OK]

Common Mistakes:

• Expecting a dict instead of an object
• Thinking output is raw binary string
• Assuming output is a list

4. You wrote this protobuf message:

message Device {
  int32 id = 1
  string name = 2;
}

When compiling, you get a syntax error. What is the problem?

medium

A. Message name cannot be Device

B. Field numbers must start at 0

C. Missing semicolon after id = 1

D. Field names cannot be id

Solution

1. Step 1: Check protobuf field syntax

   Each field line must end with a semicolon.

2. Step 2: Identify error in code

   The line int32 id = 1 misses a semicolon at the end, causing syntax error.

3. Final Answer:

   Missing semicolon after id = 1 -> Option C

4. Quick Check:

   Every field line ends with semicolon [OK]

Hint: Check every field line ends with semicolon [OK]

Common Mistakes:

• Omitting semicolon at end of field
• Wrong field numbering assumptions
• Thinking message names are restricted

5. You want to add a new optional field status (string) to an existing protobuf message without breaking compatibility. Which is the correct way?

hard

A. Add optional string status = 3; to the message

B. Change name field number to 3 and add string status = 2;

C. Remove field value and add string status = 2;

D. Add string status = 1; replacing name

Solution

1. Step 1: Understand protobuf compatibility rules

   Adding new fields with new unique numbers keeps compatibility; changing existing field numbers breaks it.

2. Step 2: Evaluate options

   Add optional string status = 3; to the message adds new optional field with new number 3, safe and compatible. Others change or remove existing fields, breaking compatibility.

3. Final Answer:

   Add optional string status = 3; to the message -> Option A

4. Quick Check:

   Add new field with new number to keep compatibility [OK]

Hint: Add new fields with new numbers, never change existing ones [OK]

Common Mistakes:

• Changing existing field numbers
• Removing existing fields
• Reusing field numbers