[grpc-io] Re: C++ buffered writes in Async client

What is the point of WriteOptions::set_buffer_hint() then? If only one write can be outstanding anyway, then I cannot simply fill-up the socket buffer for WriteOptions::set_buffer_hint() to work, because the second write can only happen after the first write has been committed and then *acked

[grpc-io] Re: C++ buffered writes in Async client

What is the point of WriteOptions::set_buffer_hint() then? If only one write can be outstanding anyway, then I cannot simply fill-up the socket buffer for WriteOptions::set_buffer_hint() to work, because the second write can only happen after the first write has been committed and then *acked

[grpc-io] Re: C++ buffered writes in Async client

What it is the point of WriteOptions::set_buffer_hint() then? If only one write can be outstanding anyway, then I cannot simply fill-up the socket buffer for WriteOptions::set_buffer_hint() to work, because the second write can only happen after the first write has been committed and then

[grpc-io] Re: C++ buffered writes in Async client

Hi, >From what I understand, it seems that you are getting bottlenecked by the network. You are right that gRPC allows only one outstanding write at any given time but that decision itself probably won't affect the throughput much. If the application does not buffer the messages, it would

[grpc-io] Re: Bare server throughtput limitation?

Hi, Though there is no inherent limitation to the number of requests that a server can handle, the sync processing model has not been the target for performance optimizations. The Async model would be better suited for performance optimizations, and you might be able to increase your

[grpc-io] Re: C++ client interceptor

Hi, Yes, we do want to stabilize the feature. We do not have a specific timeline for doing that at the moment though. On Sunday, May 17, 2020 at 5:45:28 PM UTC-7 ibnada...@gmail.com wrote: > Hi, > > gRPC appears to support C++ client interceptor, however the API is still > under experimental

[grpc-io] Re: gRFC L66: Core server RPCs will not report cancellation if completed with non-OK status

On Thursday, May 28, 2020 at 9:42:16 AM UTC-7, Vijay Pai wrote: > This clarifies and fixes the definition of the cancellation result of core > server RPCs. LGTM. -- Christopher Warrington Microsoft Corp. -- You received this message because you are subscribed to the Google Groups "grpc.io"

[grpc-io] gRPC communication across network very difficult to achieve using tutorials/examples (if it is not constrained to localhost)

To make a long story short, I had a problem whereby my client and server could not communicate with each other over the network, but after many days of working on it, I finally noticed a bit of documentation on the ASP .NET Core web pages saying that I had to add an extra setting before the

[grpc-io] gRFC L66: Core server RPCs will not report cancellation if completed with non-OK status

https://github.com/grpc/proposal/pull/179 This clarifies and fixes the definition of the cancellation result of core server RPCs. It does not affect documented and tested behavior of any of the wrapped language server APIs at the current time (C++, C#, Python, Ruby). -- You received this

[grpc-io] gRFC L66: server RPCs will not report cancellation if completed with non-OK status

https://github.com/grpc/proposal/pull/179 This clarifies and fixes the definition of the cancellation result of core server RPCs. It does not affect documented and tested behavior of any of the wrapped language server APIs at the current time (C++, C#, Python, Ruby). -- You received this