(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