Have you tried using https://grpc.io/? Streaming is supported there: https://grpc.io/docs/guides/concepts/
*From: *<sa...@cumulusnetworks.com>
*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 protobuf+unsubscr...@googlegroups.com.
> To post to this group, send email to protobuf@googlegroups.com.
> 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 protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
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
