Have you tried using https://grpc.io/? Streaming is supported there: https://grpc.io/docs/guides/concepts/
*From: *<[email protected]> *Date: *Mon, May 6, 2019 at 8:27 PM *To: *Protocol Buffers Hi, > > > this problem can be solved in below way also. > > 1. By defining new message type. > > new_message { > message a1:1; > message a2:2; > ... > message a32:32 > } > > In proto3, all the fields are optional by default. > > so no need to encode everything. But the problem is we can define more > then 32 messages because of 5-bit field value. > > But this problem can also be solved by using struct with in struct. > > new_mesasge { > message 1-32 : 1; > message 33-64 :2; > ... > } > > This way we no need to worry about Length encoding type. By using protobuf > only w can solve this problem > > Thanks > Satheesh > > > On Tuesday, February 28, 2012 at 3:57:17 AM UTC+5:30, waynix wrote: >> >> Hello All; >> >> New to protobuf and did some limited search for my question. So my >> apology if this has already been talked about. >> >> I naively thought that ParseFromFileDescriptor/ParseFromIstream would >> block on an TCP socket and return when a valid message is received. >> Read some old posts from 2010 and realized it's not that easy due to >> mesages not being self-delimiting. And the suggestion from Jason >> Hsueh was as follows: >> " >> One approach to writing multiple messages to the same stream is to use >> a >> length-delimited format: write the size of the message, then serialize >> the >> message itself. On the receiver side, you would set up a >> FileInputStream, >> and wrap a CodedInputStream around that. You can read the size of the >> messages from the stream and then use PushLimit and PopLimit to >> control how >> much data is read. >> " >> >> My quesions are: >> >> 1. Is this still the way to do it? Seems quite cumbersome (to lazy >> me ;-). Is there a wrapper built in to do this? >> 2. If I understand Jason's suggestion riht, the length is really not >> part of the message, and the sender has to explcitly set it, instead >> of having protobuf encode it in. Which means a generic third party >> sender using my .proto file would not be sufficient. Plus how would >> they know the length before encoding the message proper? Filling it in >> after the fact would change the length again? or I am totally >> missing it. >> >> 3. A related quesiton is in general do I have to manage reading of the >> socket, or for that matter any istream, and spoon feed the protobuf >> parser until it says OK, that's a whole message? >> >> 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 https://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 https://groups.google.com/group/protobuf. To view this discussion on the web visit https://groups.google.com/d/msgid/protobuf/CAEWFqPZy9_nNANYWRygRbd3iE68S1oiF8ZxbrYsy8pcfgE9iYg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
