Why can't you stream off the Self Described Messages, along with the
FileDescriptorProtos that you know about? Then to load the state you'd
effectively be executing the same exact code as the server's request
handling code (in terms of reading messages).
To create this master message, you'd need to iterate over all the
FileDescriptors that you've created, and iterate over all the message
Descriptors within each of those. You would need to create a
DescriptorProto, and for each message Descriptor, add a
FieldDescriptorProto with field type MESSAGE. You would set type_name to
the Descriptor::full_name(), and then you'll need to populate the name,
label, and number fields. Each file would need to be added as a dependency
of this dynamically generated FileDescriptorProto. Whether you add them as
extensions or regular message fields is up to you; functionally they should
be the same.
On Mon, Aug 20, 2012 at 5:09 AM, Paul Di Biase <paul.a.dibi...@gmail.com>wrote:
> At my server, we receive Self Described Messages (as defined
> which btw wasn't all that easy as there aren't any 'good' examples of this
> in c++ but was definitely manageable).
> At this point I am having no issue creating messages from these
> self-described ones. I can take the FileDescriptorSet, go through each
> adding each to a DescriptorPool (using
> which also gives me every defined FileDescriptor).
> From here I can create any of the messages which were defined in the
> FileDescriptorSet with a DynamicMessageFactory instanced with the DP and
> is very easy to do as our SelfDescribedMessage required the messages
> full_name() and thus we can call the
> of the DP, giving us the properly encoded Message Prototype).
> The question is how can I take each already defined Descriptor or message
> and dynamically BUILD a 'master' message that contains all of the defined
> messages as nested messages. This would primarily be used for saving the
> current state of the messages. Currently we're handling this by just
> instancing a type of each message in the server(to keep a central state
> across different programs). But when we want to 'save off' the current
> state, we're forced to stream them to disk as defined
> They're streamed one message at a time (with a size prefix). We'd like to
> have ONE message (one to rule them all) instead of the steady stream of
> separate messages. This can be used for other things once it is worked out
> (network based shared state with optimized and easy serialization)
> Since we already have the cross-linked and defined Descriptors, one would
> think there would be an easy way to build 'new' messages from those already
> defined ones. So far the solution has alluded us. We've tried creating our
> own DescriptorProto and adding new fields of the type from our already
> defined Descriptors but got lost (haven't deep dived into this one yet).
> We've also looked at possibly adding them as extensions (unknown at this
> time how to do so). Do we need to create our own
> unknown at this time how to do so)?
> Any insights? I've tried posting a question at
> haven't had any responses. I apologize if this isn't the correct
> location to ask this question.
> Thank You
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To view this discussion on the web visit
> To post to this group, send email to firstname.lastname@example.org.
> To unsubscribe from this group, send email to
> For more options, visit this group at
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at