في الخميس، ١٤ سبتمبر ٢٠٢٣ ٨:١٧ م 'Amirsaman Memaripour' via grpc.io <
grpc-io@googlegroups.com> كتب:
> Ho Luwei,
>
> Thanks for your response. We'd need to expand that API since the rotation
> of certificates must be controlled/guarded by a change of state in the
> system, and we may need to
And what is the BoringSSL version used there? How do we decipher it
On Wednesday, September 13, 2023 at 11:21:59 PM UTC+5:30 AJ Heller wrote:
> I'm not entirely sure how to help you with such an old version. I'd
> recommend trying with a more recent gRPC version, we are currently up to
>
Ho Luwei,
Thanks for your response. We'd need to expand that API since the rotation
of certificates must be controlled/guarded by a change of state in the
system, and we may need to process the contents of the certificate files
before loading them into memory for gRPC's consumption. My initial
Hellol
I'm using python and locust to load test grpc endpoints. I also need to
hold stream connection in addition to unary grpc calls.
So, as I see in the current implementation, it was made in
https://github.com/grpc/grpc/pull/28863
And there is the comment code:
Hello,
Can anybody give me answer to following questions.
1. No. of threads created by single gRPC CPP sync client and server
assuming we created only one stub in client side?
2. No. Of threads created by single gRPC CPP async client and server
assuming we create single stub?
Is their a way to
We are using gRPC java implementation in many of our applications across
organization. Recently, we came to know about the vulnerability as
mentioned in the subject. Please help to clarify the following points.
1. Is this vulnerability limited to C++ implementation?
2. We are using gRPC v1.37.1
