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 grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. 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.