1 stream == 1 RPC , whether it's a unary, single-sided streaming call, or bidirectional streaming call, and regardless of language. It's the basic assumption of the gRPC HTTP/2 wire format protocol.
On Wednesday, June 7, 2017 at 10:39:28 AM UTC-7, Vivek M wrote: > > Hi Naoh, > > Surely I can try these. Nice to hear that flow control is being worked > out, what timeline/release can it be expected? > > Before trying out your suggestions I would also like to know when there > are lets say 10 streams (each 1 MB) per connection (10 MB is total > connection window size as negotiated by client) and there is a server > streaming call in progress, can all these 10 streams be potentially used by > this one streaming call? I assume no as gRPC doesn't guarantee in-order > delivery and hence only one stream will be in use per RPC call. Correct me > if my understanding is wrong. > > Thanks, > Vivek > > On 7 June 2017 at 20:25, Noah Eisen <[email protected] <javascript:>> > wrote: > >> Hi Vivek, >> >> Linking myself in since I have been working on c core flow control these >> days. Neither the grpc_fd objects, or the flow control parameters are made >> available to the user. This is a very conscious choice as we want to do all >> the fd bookkeeping ourselves and we want to optimize flow control >> ourselves. At the moment there are some known issues with flow control >> stalls under large message throughput situations, but that is under >> investigation. >> >> In the mean time, you are welcome to do some experimentation, but it will >> have to happen through actually modifying the c core. Here are some >> interesting places you might look in the code based on this discussion and >> the on you had with Carl in a different thread: >> >> target_write_size() >> <https://github.com/grpc/grpc/blob/master/src/core/ext/transport/chttp2/transport/writing.c#L176> >> is >> where we set a target size for the chunks actually hitting a write syscall. >> It's currently 1M >> >> update_bdp() >> <https://github.com/grpc/grpc/blob/master/src/core/ext/transport/chttp2/transport/chttp2_transport.c#L2314> >> is >> where we update the connection's initial window to our estimate of the bdp. >> Note that a few lines later we update the max frame size to max(bdp and >> bandwidth per ms). I saw you mentioned this in the other thread. >> >> Check those out to start. We can keep discussing in this thread if you >> want to start experimenting with performance. I am currently working on >> refactoring the flow control code to exist in one module with a clear >> interface. >> >> Hope this helps! >> Noah >> >> On Wed, Jun 7, 2017 at 12:43 AM, Vivek M <[email protected] <javascript:> >> > wrote: >> >>> Hi Vijay, >>> >>> Any thoughts on this? >>> >>> Thanks, >>> Vivek >>> >>> On Friday, June 2, 2017 at 11:40:43 PM UTC+5:30, Vivek M wrote: >>>> >>>> Hi Vijay, >>>> >>>> I was also wondering if there is a way to get this. >>>> >>>> Lets say a client negotiates a HTTP/2 window size of 1 MB and the >>>> server sets its send window size to 1 MB. However if the underlying TCP >>>> socket's send buffer size is 64 KB (default value in FreeBSD), then I >>>> think >>>> only 64KB of data will be in flight. This may affect the throughput. >>>> >>>> So if there is an option to get both the FD being used for an RPC() and >>>> the maximum window size that has been negotiated by the client, then we >>>> can >>>> try to increase the send buffer size (if our system permits) in the >>>> application. >>>> >>>> Thanks, >>>> Vivek >>>> >>>> On Tuesday, May 23, 2017 at 9:19:35 AM UTC+5:30, Richard Chan wrote: >>>>> >>>>> hi >>>>> >>>>> i want to get grpc server fd, to polling the fd in my code. >>>>> is there any existing api to accomplish this ? >>>>> >>>>> i only see make grpc from fd in server_posix.h >>>>> >>>>> -- >>> 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] <javascript:>. >>> To post to this group, send email to [email protected] >>> <javascript:>. >>> 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/7d6f8bca-5a2e-44ba-aff6-6ea7eca25c93%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/grpc-io/7d6f8bca-5a2e-44ba-aff6-6ea7eca25c93%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- 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/0fb52850-dc30-4e6f-86b2-6e2bdc13ba6f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
