Your understanding is correct. You may want to consider using streaming
instead of repeated field if the aggregate response size is very large
which can cause out-of-memory or flow control issues in your application.
Using unary for large repeated response has no big benefits over streaming.
Even in the case of large unary response, the HTTP/2 transport will break
it up into smaller frames and stream it to the client. It is assembled back
into a single response before presenting it to the application.
In gRPC, client always initiates the RPC which translates to client always
initiating the stream.
On Friday, April 5, 2019 at 12:44:46 PM UTC-7, chirag shah wrote:
>
> I think I found some clarification which is like...
>
> In general, if your use case would allow the client to process the
> incoming messages one at a time, the stream is the better choice.
> If your client will just be blocking until all of the messages arrive and
> then processing them in aggregate, the repeated field may be appropriate.
>
> So looks like both the approaches are correct.
>
> In that case, in the gRPC no matter which kind of streaming we are doing
> (i.e., client-side, server-side or bidirectional) my understanding is
> the HTTP/2 stream that gets created underneath is always initiated by the
> client. Server is not creating the HTTP/2 stream.
>
> Am I correct ?
>
>
>
> Thanks.
>
> On Friday, April 5, 2019 at 1:38:06 PM UTC-5, chirag shah wrote:
>>
>> Hello ,
>>
>>
>> In gRPC we have 4 typical ways of client-server communication. Let’s
>> pick server-streaming.
>>
>> As we know Server streaming meaning a single client request triggers
>> multiple response from the server. I wanted to zoom into this line.
>>
>> Let’s say following is one such method in the service of my
>> protocol-buffer file.
>>
>> *rpc ListFeatures(Rectangle) returns (stream Feature)*
>>
>>
>>
>> This method obtains the Features available within the given Rectangle.
>>
>> Results are streamed rather than returned at once (e.g. in a response
>> message with a repeated field), as the rectangle may have huge number of
>> features.
>>
>> But that is exactly what I am not following.
>>
>> Just because server wants to send more than one Feature object, that
>> should not be a qualification for using Stream (I can do it with Unary call
>> too)
>>
>> If server wants to send multiple feature objects, in my proto-buffer
>> file, I can create a wrapper message object like
>>
>> message FeatureResponse {
>>
>> repeated Feature features = 1;
>>
>> }
>>
>>
>>
>> message Feature {
>>
>> string url = 1;
>>
>> string title = 2;
>>
>> }
>>
>>
>>
>> And now server can expose *rpc ListFeatures(Rectangle) returns
>> (FeatureResponse) This is Unary call.*
>>
>>
>>
>>
>>
>> My understanding about using Server-side-Streaming RPC call is *when the
>> server does not have all the complete data right when the RPC call came
>> from the client (Or expecting more and more data along with the time)*
>>
>> So when client call method *ListFeatures*, server prepares
>> FeatureResponse and stuff as many Features as possible at that point of
>> time and push it out to the client on the HTTP2 stream initiated by the
>> client.
>>
>> It however, knows that after some time (for eg., 15 min) he is going to
>> get another set of Features object to send out.
>>
>> So that time it will use the SAME logical HTTP2 stream to push out those
>> new objects.
>>
>>
>>
>> Am I correct ? If not how can we realize above business situation where
>> server for eg., has to push out the latest stock prices every 30 min .
>>
>>
>>
>> Really appreciate your help demystifying this concept.
>>
>>
>>
>> Thanks.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" 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/grpc-io.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/2402699e-19ec-440b-ac10-a451ba0ed1f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
