On Thursday, October 5, 2023 at 12:10:37 AM UTC-7 Razvan Simerea wrote:
> In the Microsoft docs on gRPC interceptors for .NET it is said that:
>
> "gRPC server interceptors intercept incoming RPC requests. They provide
> access to the incoming request, the outgoing response, and the context for
>
On Tuesday, February 21, 2023 at 12:15:04 PM UTC-8 Amirsaman Memaripour
wrote:
> I am working on a client/server implementation for a gRPC service, where
> both server and client will be written in C++. The server and client will
> use bidirectional streams to communicate, and need to send raw
On Wednesday, August 17, 2022 at 3:02:55 PM UTC-7 cruise...@gmail.com wrote:
> Is there an example of how to use a gRPC client/server with just a buffer
> payload? The closest answer I've seen so far is that it requires a
> protobuf message with a bytes field
Serialization is controlled by
On Sunday, November 14, 2021 at 9:59:34 PM UTC-8 Rajanarayana A wrote:
> I see that there is a possibility of one instance of CallData being
> accessed in multiple threads (returned as part of tag). Is CallData
> thread-safe here or do we need to have a mutex for the same?
There's an older
On Monday, November 22, 2021 at 7:09:22 PM UTC-8 meng...@gmail.com wrote:
> I didn't have any hint to locate which connection/fd from this 'tag'. I
> think grpc have some record to pair this 'tag' with connection. And if one
> client send multiple requests, each request has its own 'tag', but
On Friday, November 19, 2021 at 3:07:02 PM UTC-8 meng...@gmail.com wrote:
> If i use one completion queue in server side to handle all of the
> connections, for each return from cq.AsyncNext, how do i know which
> connection it is.
You will need to augment CallData with these sort of details.
On Tuesday, March 30, 2021 at 1:00:21 AM UTC-7 Vivek wrote:
> As I mentioned the Trailer approach comes with some caveats. Hence, I
> wanted to know if there is a better way to do this esp. Fault Contract
> approach mentioned here:
>
On Monday, March 29, 2021 at 1:33:03 PM UTC-7 Vivek wrote:
> Rich error model is currently not supported in C#.
While there's nothing built-in to either gRPC C# or gRPC.NET (yet?), you can
implement it manually. I have a fully working gRPC.NET example at
On Wednesday, February 3, 2021 at 8:14:54 AM UTC-8 Luke S wrote:
> ... to obtain the version of protoc/plugin to enable me to generate these
> more modern files for our clients?
Typically, one shares the .proto files with consumers--not the generated
code. This lets them generate code however
On Friday, November 27, 2020 at 11:05:39 AM UTC-8 Joseph Liu wrote:
> Instead, the logic for handling `SayHello` seems to be handled in the
> `Proceed` function. If I wanted to create another method, do I just handle
> it all in Proceed? And if so, how would I do that?
A high level flow that you
On Saturday, October 10, 2020 at 6:02:04 AM UTC-7 yabo...@gmail.com wrote:
> for heavy and perf critical APP, exception dispatching is also a perf
> concern, is it possible to avoid throwing rpcException? (especially on
> client side). With that, the Application layer code can look into the
>
On Monday, August 17, 2020 at 3:27:37 PM UTC-7, Marco Argentieri wrote:
> I want to be able to use the Noise Protocol to securely perform mutual
> authentication and end to end encrypt the messages exchanged.
>
> ...
>
>But, would be way nicer if a three act ECDH key exchnage for subsequent
On Wednesday, August 19, 2020 at 10:32:53 AM UTC-7, Wensheng Tang wrote:
> I fully understand that the gRPC does not allow some status codes to
> return to its user. However, the second function `verify_frame_header()`
> does return `GRPC_STATUS_FAILED_PRECONDITION`, which is also on the
>
On Friday, June 19, 2020 at 6:25:28 PM UTC-7, sathya M wrote:
> As you mentioned, I have done a shutdown as per the documents comment
> given. As per the document given, Completion Queue will get drained only
> after the CQ shutdown.
That's not _quite_ what the documentation says. It says that
On Wednesday, June 17, 2020 at 11:11:22 PM UTC-7, sathya M wrote:
> so what is the correct steps for graceful shutdown ?
Take a look at the doc comments for ServerBuilder's AddCompletionQueue
member function [1]. It describes the canonical way to shutdown an async
server.
The assert is because
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"
On Friday, April 17, 2020 at 1:52:16 AM UTC-7, kimsur...@gmail.com wrote:
> Using the / clr compile option results in an error.
>
> ERROR C1189 #error: is not supported when compiling with /clr or
/clr:pure
Have you looked at using the C# packages (Grpc.Core ) [1] from managed
C++? That may be
On Monday, April 6, 2020 at 8:37:20 AM UTC-7, stvanhe...@gmail.com wrote:
> I did try out specifying a past deadline and it indeed allows you
> to check for completed events and returning instantly if there are none.
One thing to be aware of: the completionq queue "borrows" the threads that
are
On Wednesday, March 11, 2020 at 1:30:57 PM UTC-7, Martin Scholz wrote:
> Is there any documentation how gRPC on server side with .NET or C# is
> handling multiple request under the hood.
The closest that I know of is the GrpcEnvironment API documentation [1].
> Does every request consume a
On Tuesday, March 10, 2020 at 1:33:52 PM UTC-7, Moiz Haidry wrote:
MH> There is a note in the proposal under grpc plugin credentials mentioning
MH> that this a breaking API change. Please let me know if there needs to be
MH> more details provided.
The proposal has this:
> The caller has to
On Wednesday, February 19, 2020 at 9:40:14 AM UTC-8, Moiz Haidry wrote:
> This is an effort to add more debugging capability to the gRPC core
> surface API.
During the PR, Vijay Pai mentioned [1] that the addition of the debug_string
member to the grpc_metadata_credentials_plugin is an API
On Monday, December 16, 2019 at 5:16:48 AM UTC-8, Daniel wrote:
> Is it possible to somehow name the threads that are spawned by grpc?
Which language are you using? Which implementation of gRPC are you using?
--
Christopher Warrington
Microsoft Corp.
--
You received this message because you
On Thursday, December 5, 2019 at 12:31:56 PM UTC-8, Yihua Zhang wrote:
> I have created a gRFC - https://github.com/grpc/proposal/pull/167
>
> Please let me know your comments on this thread.
I think it would be useful to add to the proposal:
* an explanation of the pros/cons that lead to the
On Thursday, August 22, 2019 at 8:30:09 AM UTC-7, Esun Kim wrote:
> That's a good point. I'll update the doc to include more about
> platform-specific issues.
I just saw the updates to the proposal [1]. They look good to me. Thank you.
[1]: https://github.com/grpc/proposal/pull/156
--
On Tuesday, August 20, 2019 at 4:30:29 PM UTC-7, Esun Kim wrote:
> This is the discussion thread for L59 - Allow C++ standard library in gRPC
> Core Library
The biggest thing I see missing from this proposal is how it affects
platforms other than Linux. There is no mention of macOS or Windows. I
On Monday, June 24, 2019 at 10:32:19 AM UTC-7, Yaxiong Zhao wrote:
> The doc (https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md)
> says TE → "te" "trailers" # Used to detect incompatible proxies. I have no
> idea how it's used for detecting incompatible proxies.
Does the HTTP2 spec
I created a PR with a build fix for the CMake build on May 7, #18984 "Fix
CMake upb build: add missing headers directory" [1]. It's been needing a
review from someone on the gRPC team since then. I've pinged the PR three
times since then. Is there something else I should be doing to get this
On Tuesday, June 11, 2019 at 3:29:03 PM UTC-7, Soheil Hassas Yeganeh wrote:
> I added a brief explanation in the abstract, hoping that it would
address your concern.
Your update looks good to me.
--
Christopher Warrington
Microsoft Corp.
--
You received this message because you are
On Tuesday, June 11, 2019 at 12:06:44 PM UTC-7, Soheil Hassas Yeganeh wrote:
> This is the discussion thread for L52 gRFC: Require static strings for
> method and host passed to grpc_channel_register_call()
Consider adding a definition of what is meant by "static string". My first
reaction was
On Tuesday, March 12, 2019 at 3:22:26 AM UTC-7, maxwel...@gmail.com wrote:
> Ah, so the server is also running if I dont call wait?
Yes. Among other things, BuildAndStart() starts listenting for requests.
Wait() is using during shutdown typically. Here's an excerpt from the
documentation for
> adding msbuild integration support into the Grpc.Tools nuget package.
The is very good news! I gave it a test run on some of my projects and its
working just fine, including imports and well-known .protos.
I haven't needed to use more advanced features yet.
I've sidled up to this in a
On Friday, October 12, 2018 at 1:53:15 PM UTC-7, Arpit Baldeva wrote:
> As for boiler plate, yeah, the async grpc version forces lot of it. So the
> implementation above and a custom code generator plugin can go a long way
> into making that process nice. For example, with a custom code
On Tuesday, October 2, 2018 at 12:03:06 PM UTC-7, toka...@gmail.com wrote:
> libgrpc_csharp_ext.x64.so, the native Grpc library for Linux, is 15.2 Mb.
> For my application the size of the package is key (it runs in a
> containerized environment). I'm using an ultra-small Linux image, Alpine,
>
On Tuesday, August 21, 2018 at 3:28:24 AM UTC-7, Pau Freixes wrote:
> I've realized reading the current Grpc code that exists [1] other
> alternatives to the completion queue next, the pluck and the callback
> one.
>
> I've been trying to seek some information, or usage, of these
> alternatives
> I belive then that you want
com.google.protobuf.MessageList.getSerializedSize() [1].
Correction: the interface is MessageLite, not MessageList.
--
Christopher Warrington
Microsoft Corp.
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To
On Thursday, May 17, 2018 at 2:31:37 PM UTC-7, jojy.v...@gmail.com wrote:
> If we have a polling thread that polls a CQ(calls next), it would mean
> that the polling thread would be doing the IO also right? I say this
> because if a client connection "writes" something, then that write will be
>
On Monday, May 14, 2018 at 8:51:29 AM UTC-7, jojy.v...@gmail.com wrote:
> Had a question: How can we multipllex connections over handful of CQs?
> Dont all the individual client (represented by its unique *tag*) have to
> poll on the CQs in its own thread? Which means we need N number of threads
>
On Wednesday, May 9, 2018 at 2:05:32 PM UTC-7, jojy.v...@gmail.com wrote:
>>> For every connection, we should be able to get the events unique to that
>>> connection in completion queue
>> Pretend you had such an API. Can you share how you would make us of it
>> and what higher-level problem it
On Tuesday, May 8, 2018 at 9:32:25 AM UTC-7, jojy.v...@gmail.com wrote:
> - For every connection, we should be able to get the events unique to
that connection in completion queue
Pretend you had such an API. Can you share how you would make us of it and
what higher-level problem it would let
> I am having difficulty implementing "no parallel execution" guarantee --
> if worker (or connection to it) goes down I need to recognize this in
> Coordinator, "pause" all jobs given worker was running and (after some
> timeout or user action) re submit jobs to another worker. Timeout (or user
>
Looking at the implementation, this inherits from
::grpc::protobuf::io::ZeroCopyOutputStream,
which implies a dependency on protobuf.
Is that the case?
* If so, should this be called, say, GrpcProtoBufferReader instead?
* If this isn't used by the client of gRPC, can building and
>From the proposal:
> If the method handler throws a std::exception, the sync server will treat
> it as though it returned an UNKNOWN Status marked with the what result of
> the exception as its error message.
Is the proposed behavior in line with the security model used for gRPC's
default
On Saturday, October 28, 2017 at 10:00:45 AM UTC-7, Vijay Pai wrote:
> grpc::Slice drops a reference to the underlying grpc_slice at destruction
> time; if you use that in combination with the StealRef second argument, I
> think that you would have what you essentially want. (FWIW, the
>
Are there any C++ RAII wrappers for
grpc_byte_buffer/grpc_slice/grpc_byte_buffer_reader & friends? I couldn't
find any in a cursory look.
I only really interact with these types in my specialization of
grpc::SerializationTraits. The rest of the time I'm well insulated from
them.
--
> Per the gRFC process, please keep discussion in this thread.
There seems to be significant discussion going on in the pull request. I
have some comments. Would they be preferred here or
at https://github.com/grpc/proposal/pull/38?
--
You received this message because you are subscribed to
45 matches
Mail list logo
