Yes, it is common in bidirectional streaming RPCs for the server to send
messages before the client ends its side of the stream. For example, the
server could respond to each message the client sends with a message,
indefinitely, without the stream ever intentionally closing.
On Mon, Jan 22, 2024
Ok got it.
I was thinking that in a bidirecttional streaming RPC, the server can start
sending out replies even before an END STREAM is received (from the DATA
frame header). So it's like, (1) the server parses one grpc length prefixed
message, (2) call user defined functions, (3) sends it
Looks like the information I'm looking for may be here:
https://github.com/grpc/grpc/tree/v1.60.0/third_party/cares
If I'm understanding this correctly, gRPC 1.60.0 should be running c-ares
1.19.1.
On Thursday, January 18, 2024 at 8:13:34 PM UTC-5 Nicholas Chammas wrote:
> How can I tell what
Hello,
I need to build gRPC with gcc on mac. When trying to do so,
boringssl-with-basel compilation fails with:
*[ 12%] Building ASM object
third_party/boringssl-with-bazel/CMakeFiles/crypto.dir/apple-aarch64/crypto/chacha/chacha-armv8-apple.S.oclang:
error: unsupported option
No. In a stream, the contents of all of the DATA frames sent in one
direction are collectively treated as a byte stream that contains
length-delimited gRPC messages, independent of the DATA frame boundaries.
In other words, any single DATA frame can contain only part of a message,
or multiple
Hello,
Does "hedgingPolicy" is suported for C++ grpc or not?
I see description for hedging in proposal,
https://github.innominds.com/grpc/proposal/blob/master/A6-client-retries.md,
but I do not see that the configuration parameters for hedgind are parsed
in the code.
I use grpc 1.54.2
Best
