Yep, that's described here:
http://code.google.com/apis/protocolbuffers/docs/techniques.html#union

On Fri, Jun 19, 2009 at 1:00 PM, Jesper Eskilson <jes...@eskilson.se> wrote:

> (Sorry Kenton, I missed adding the list as recipient...)
>
> We're using a very simple approach where we send only one type of
> message containing a type-enum and one or more optional fields (I
> think this technique is described in the manual). In order to be able
> to read the message in full before parsing it, we first send a 32-bit
> integer containing the size of the message, and then read that many
> bytes. Really not very complicated.
>
> On Fri, Jun 19, 2009 at 10:53 AM, Kenton Varda<ken...@google.com> wrote:
> > No, protocol buffers are not self-describing.  The receiver needs to know
> > what type it is receiving, or you need to send the type information over
> the
> > wire separately.
> >
> > On Fri, Jun 19, 2009 at 1:10 AM, brodie <brofi...@gmail.com> wrote:
> >>
> >> If the entire message needs to be in the buffer at one time before it
> >> can be parsed out, then it makes parsing out the messages easier. i.e.
> >> either the message is complete or not. Is there an interface to parse
> >> a generic message from the buffer? There doesn't seem to be. I'm
> >> envisaging usage something like this...
> >>
> >> something buf;
> >> Message * msg
> >> while (receiveData(&buf)) {
> >>  rc = Factory::parse(buf, &msg);
> >>  if (rc == INCOMPLETE) continue;
> >>
> >>  switch (msg->type()) {
> >>  ... process ...
> >>  }
> >> }
> >>
> >> The proto2 RPC doesn't appear to fit my usages because my message
> >> stream is not strictly request/response. There can be multiple request
> >> messages in a row, ditto for responses.
> >>
> >> Regards,
> >> Brodie
> >>
> >>
> >> On Jun 19, 12:47 pm, Kenton Varda <ken...@google.com> wrote:
> >> > On Thu, Jun 18, 2009 at 8:47 PM, Kenton Varda <ken...@google.com>
> wrote:
> >> > > Note that the protocol buffer parser is not asynchronous.  That
> means
> >> > > you
> >> > > either need to feed it an entire message at once, or it will need to
> >> > > block
> >> > > waiting for mode data to arrive on
> >> >
> >> > s/mode/more
> >> >
> >> > > the input stream.  So if you want to do something asynchronous, you
> >> > > best
> >> > > bet is probably to do your own buffering until you have received an
> >> > > entire
> >> > > message, then pass the bytes off to the protobuf parser.  You
> probably
> >> > > won't
> >> > > need to implement any custom ZeroCopyStreams for that.
> >> >
> >> > > On Thu, Jun 18, 2009 at 8:30 PM, brodie <brofi...@gmail.com> wrote:
> >> >
> >> > >> Hi all,
> >> >
> >> > >> Has anyone done any work to create a stream implementation for
> async
> >> > >> use? In particular, Windows async sockets or async named pipes?
> >> >
> >> > >> I'm planning to implement PB as the messaging layer on top of a
> >> > >> Windows sockets transport layer (therefore using HANDLE instead of
> a
> >> > >> file descripter). We may additionally make this layer swappable
> with
> >> > >> named pipes (also a HANDLE). Transport in both cases will be done
> >> > >> async. On Linux/OSX we will just use async sockets.
> >> >
> >> > >> It would be nice if someone has already done some work in this area
> >> > >> that I can leverage/build on. Any pointers?
> >> >
> >> > >> Regards,
> >> > >> Brodie
> >>
> >
> >
> > > >
> >
>
>
>
> --
> /Jesper
> #include "witty-quote.h"
>

--~--~---------~--~----~------------~-------~--~----~
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 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to