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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
