i currently try to build some small framework that eases the usage of
protocol buffer for a project of me.

The system allows for easier protocol handling and is composed of this:
- a PacketManager responsible for dispatching recieved messages
(bytebuffers) to PacketHandlers
- several PacketHandlers that are able to handle one specific message
described by a .proto file

The PacketHandlers know which message type of the available they can handle
and tell this information to the PacketManager when they are registered.
The overall logic already works, but the main problem is how to detect
which kind of message is recieved (and therefore which PacketHandler must
be called to handle the message). I tried to solve this by an header
message with an id-field with a default value, but this wont work because
the id field is not set and therefore cant be extracted from the

This problem however can be overcome when at message construction time the
type is explicitely set. But i wanted to implement a way the user need not
to deal with message ids but can concentrate on the payload data.
It would be cool if one can define "hardcoded" fields in the protocol
definition file so that those values are always sendet over the wire and
are (optionally) immutable.

---File: net.proto---

message Header {
optional int32 type = 1;
message TestMessage {
optional int32 type = 1 [default=10];

required string msg = 2;
^^ since TestMessage.type is not set in source code, it will not be sent
over the wire. I know that with "required" i could force the user to set
that field, but it would be good if he didnt need to deal with that:

---File: net.proto.advanced---

message Header {
required int32 type = 1;
message TestMessage {
optional int32 type = 1 [static=10];

required string msg = 2;

Most probably im just missing something important as im new to this topic.
With best regards!

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to