Re: how to handle message spanning multiple packets?

2008-09-08 Thread Kenton Varda
They are just abstract interfaces.  You have to implement them.  For
examples, I suppose you could look at some of the RPC implementations people
are working on:
http://code.google.com/p/protobuf/wiki/RPCImplementations

On Mon, Sep 8, 2008 at 10:34 AM, Mateusz Berezecki <[EMAIL PROTECTED]>wrote:

> On Mon, Sep 8, 2008 at 7:26 PM, Kenton Varda <[EMAIL PROTECTED]> wrote:
> > Protocol Buffers solve the problem of converting structured data into a
> flat
> > byte array.  They do not solve the problem of communicating that byte
> array
> > over a network; that's the job of some other library.  Sorry to
> disappoint.
>
> Hello Kenton,
>
> It's not that much of a disappointment. I was having a perception
> it does solve this particular problem based on the "media coverage".
>
> Anyway, could you please point me to some examples or perhaps
> explain how to use RpcChannel and RpcController classes?
>
> The information in the documentation is rather scarce.
>
> Mateusz
> >
> > On Sun, Sep 7, 2008 at 10:58 AM, Mateusz Berezecki <[EMAIL PROTECTED]>
> > wrote:
> >>
> >> Hello Group,
> >>
> >> I have a question that worries me for some time now,
> >> and I have not found any answer for it.
> >>
> >> How am I supposed to handle messages
> >> spanning multiple packets of a connectionless protocol ?
> >> I am thinking UDP here.
> >>
> >> All is good if the message can be contained inside a single
> >> UDP packet, but what if it does not ?
> >>
> >> What if the message spans K packets ?
> >> ParseFromString no longer works as I don't know
> >> the message length , and how many packets it spans.
> >>
> >> How do I discover the message length dynamically,
> >> after only receiving a part of it???
> >>
> >> I could of course monitor packets, prepend length information
> >> on top of protobuf message (but this adds yet another
> >> data description layer on top of protobuf, so it defeats
> >> the purpose of having protobufs at all), then start sort of
> >> "journalling"
> >> the packets, and start managing incoming fragments, and merge
> >> them when appropriate and finally deserialize them.
> >>
> >>
> >> But, I thought that it was done within the protobuf (yes, I am
> >> seriously disappointed,
> >> because the whole library is now seriously crippled :-( ) !
> >>
> >> Apparently it is not.
> >>
> >> So, I started looking at RPC services but this what was
> >> supposed to be a best thing in the whole library,
> >> suddenly suffers from basically no documentation,
> >> and no examples whatsoever.
> >>
> >>
> >> Is there a way to solve my problem in an _elegant_ way ?
> >> I am into a solution that utilizes protobuf's RPC channels/controllers
> >> even though I have no friggin idea how to use them :-) but I have
> >> an intuition that tells me that's the way to do it.
> >>
> >> So, could anyone please describe their experience and some
> >> guidelines (an example would be nice too) on
> >> solving this kind of problem?
> >>
> >>
> >> Mateusz
> >> > >>
> >
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---



Re: how to handle message spanning multiple packets?

2008-09-08 Thread Mateusz Berezecki

On Mon, Sep 8, 2008 at 7:26 PM, Kenton Varda <[EMAIL PROTECTED]> wrote:
> Protocol Buffers solve the problem of converting structured data into a flat
> byte array.  They do not solve the problem of communicating that byte array
> over a network; that's the job of some other library.  Sorry to disappoint.

Hello Kenton,

It's not that much of a disappointment. I was having a perception
it does solve this particular problem based on the "media coverage".

Anyway, could you please point me to some examples or perhaps
explain how to use RpcChannel and RpcController classes?

The information in the documentation is rather scarce.

Mateusz
>
> On Sun, Sep 7, 2008 at 10:58 AM, Mateusz Berezecki <[EMAIL PROTECTED]>
> wrote:
>>
>> Hello Group,
>>
>> I have a question that worries me for some time now,
>> and I have not found any answer for it.
>>
>> How am I supposed to handle messages
>> spanning multiple packets of a connectionless protocol ?
>> I am thinking UDP here.
>>
>> All is good if the message can be contained inside a single
>> UDP packet, but what if it does not ?
>>
>> What if the message spans K packets ?
>> ParseFromString no longer works as I don't know
>> the message length , and how many packets it spans.
>>
>> How do I discover the message length dynamically,
>> after only receiving a part of it???
>>
>> I could of course monitor packets, prepend length information
>> on top of protobuf message (but this adds yet another
>> data description layer on top of protobuf, so it defeats
>> the purpose of having protobufs at all), then start sort of
>> "journalling"
>> the packets, and start managing incoming fragments, and merge
>> them when appropriate and finally deserialize them.
>>
>>
>> But, I thought that it was done within the protobuf (yes, I am
>> seriously disappointed,
>> because the whole library is now seriously crippled :-( ) !
>>
>> Apparently it is not.
>>
>> So, I started looking at RPC services but this what was
>> supposed to be a best thing in the whole library,
>> suddenly suffers from basically no documentation,
>> and no examples whatsoever.
>>
>>
>> Is there a way to solve my problem in an _elegant_ way ?
>> I am into a solution that utilizes protobuf's RPC channels/controllers
>> even though I have no friggin idea how to use them :-) but I have
>> an intuition that tells me that's the way to do it.
>>
>> So, could anyone please describe their experience and some
>> guidelines (an example would be nice too) on
>> solving this kind of problem?
>>
>>
>> Mateusz
>> >>
>
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---



Re: how to handle message spanning multiple packets?

2008-09-08 Thread Kenton Varda
Protocol Buffers solve the problem of converting structured data into a flat
byte array.  They do not solve the problem of communicating that byte array
over a network; that's the job of some other library.  Sorry to disappoint.

On Sun, Sep 7, 2008 at 10:58 AM, Mateusz Berezecki <[EMAIL PROTECTED]>wrote:

>
> Hello Group,
>
> I have a question that worries me for some time now,
> and I have not found any answer for it.
>
> How am I supposed to handle messages
> spanning multiple packets of a connectionless protocol ?
> I am thinking UDP here.
>
> All is good if the message can be contained inside a single
> UDP packet, but what if it does not ?
>
> What if the message spans K packets ?
> ParseFromString no longer works as I don't know
> the message length , and how many packets it spans.
>
> How do I discover the message length dynamically,
> after only receiving a part of it???
>
> I could of course monitor packets, prepend length information
> on top of protobuf message (but this adds yet another
> data description layer on top of protobuf, so it defeats
> the purpose of having protobufs at all), then start sort of
> "journalling"
> the packets, and start managing incoming fragments, and merge
> them when appropriate and finally deserialize them.
>
>
> But, I thought that it was done within the protobuf (yes, I am
> seriously disappointed,
> because the whole library is now seriously crippled :-( ) !
>
> Apparently it is not.
>
> So, I started looking at RPC services but this what was
> supposed to be a best thing in the whole library,
> suddenly suffers from basically no documentation,
> and no examples whatsoever.
>
>
> Is there a way to solve my problem in an _elegant_ way ?
> I am into a solution that utilizes protobuf's RPC channels/controllers
> even though I have no friggin idea how to use them :-) but I have
> an intuition that tells me that's the way to do it.
>
> So, could anyone please describe their experience and some
> guidelines (an example would be nice too) on
> solving this kind of problem?
>
>
> Mateusz
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---