PB's don't include any protocol at all. Your RPC mechanism will need to provide for this. It's common to do something like a <length> <pb> type of thing; you could even use the CodedOutputStream (or its equivalent, depending on the language you're using) to emit the length as a varint, and then stick the pb into it. You do need to pre-serialize the pb though, so if it's going to be huge, that can be a problem. (One could come up with ways to mitigate that of course.)
On Mon, Mar 31, 2014 at 4:43 PM, Iñaki Baz Castillo <[email protected]> wrote: > Hi, > > I want to send PB messages to a server via a persistent TCP connection. The > idea is that the client can send lot of messages one behind the other over > the same TCP connection. This means that data received in the server may be > a complete PB message, a portion of a PB message, or more than a single PB > message. > > Is the protocol ready for this case? is there a parsing API for this case? > or should I add some kind of data delimiter and perform manual parsing on > server side in order to parse single and entire PB received messages? > > Thanks a lot. > > -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/protobuf. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
