[grpc-io] gRPC programming guideline: When to convert status codes?

[Wensheng Tang]

Dear gRPC developers,

We notice that there are many cases gRPC or other status codes are being 
converted internally through our code analyzer.

For example, in
https://github.com/grpc/grpc/issues/23775

The error code from

```c
// may return GRPC_STATUS_INVALID_ARGUMENT
status = gsec_aead_crypter_decrypt_iovec(...);
if (status != GRPC_STATUS_OK) {
return GRPC_STATUS_INTERNAL;
}
```
, the original status code is dropped. I believe such a conversion is not 
needed. Besides, it may not present the real errors to its client, which 
may not follow guidelines 
in https://grpc.github.io/grpc/core/md_doc_statuscodes.html.

On another hand, in the same function, it does keep the original status 
codes, some times.

```c
grpc_status_code status = verify_frame_header(...);
if (status != GRPC_STATUS_OK) {
return status;
}
```

Your team closes my issues so quickly so I am not sure if here is the right 
place to report. Shall we confine a clear and general guideline of when to 
convert status codes internally?

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/c0fcae1a-7070-43b0-949e-1b043b8f7233n%40googlegroups.com.

Re: [grpc-io] Re: grpc-python bidirectional streaming delivery status

[Sudharsan R]

Thanks.

On Wed, Aug 12, 2020 at 12:09 PM 'Richard Belleville' via grpc.io <
grpc-io@googlegroups.com> wrote:

> gRPC does not handle application-level acknowledgement of receipt of
> messages. If you want to do this, you'll have to add it into your protocol.
> Your method might look something like this:
>
>
> syntax = "proto3";
>
> message MetricRequest {
>   ...
> }
>
> message MetricResponse {
>   oneof payload {
> google.protobuf.Empty ack = 1;
> ... // Whatever the original intended response was.
>   }
> }
>
> service MultiGreeter {
> rpc MetricReport (MetricRequest) returns (stream MetricResponse) {}
> }
>
> Your server would then immediately acknowledge receipt of a client request
> by sending a MetricResponse with only the ack field set.
>
> Thanks,
> Richard
> On Thursday, August 6, 2020 at 6:27:50 PM UTC-7 sud@gmail.com wrote:
>
>> Hi all,
>> I must be missing something simple. I'm using the python client to
>> generate RPC messages for a bidirectional streaming service. The server is
>> in java and generates messages very rarely. How can i at a grpc level know
>> if messages have been delivered to the business logic on the server side?
>>
>> This is an example i see at many places:
>>
>> response = stub.MetricReport(iter(repeated_metric()))
>>
>> for r in response:
>>
>>//Do something with response
>>
>>
>> However, this seems to be a blocking call and like i said the server
>> rarely responds. What can i look at from a grpc level to get delivery
>> status?
>>
>> Thanks
>> Sudharsan
>>
>>
>>
>> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/e58be813-276e-4f09-bbc6-1927a446180bn%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAOduwEgUnOj8FCawaiK8kWR74uLkgGHT9v84Htm4z63%2Bd0g0AQ%40mail.gmail.com.

[grpc-io] Re: grpc-python bidirectional streaming delivery status

['Richard Belleville' via grpc.io]

gRPC does not handle application-level acknowledgement of receipt of 
messages. If you want to do this, you'll have to add it into your protocol. 
Your method might look something like this:


syntax = "proto3";

message MetricRequest {
  ...
}

message MetricResponse {
  oneof payload {
google.protobuf.Empty ack = 1;
... // Whatever the original intended response was.
  }
}

service MultiGreeter {
rpc MetricReport (MetricRequest) returns (stream MetricResponse) {}
}

Your server would then immediately acknowledge receipt of a client request 
by sending a MetricResponse with only the ack field set.

Thanks,
Richard
On Thursday, August 6, 2020 at 6:27:50 PM UTC-7 sud@gmail.com wrote:

> Hi all,
> I must be missing something simple. I'm using the python client to 
> generate RPC messages for a bidirectional streaming service. The server is 
> in java and generates messages very rarely. How can i at a grpc level know 
> if messages have been delivered to the business logic on the server side?
>
> This is an example i see at many places:
>
> response = stub.MetricReport(iter(repeated_metric()))
>
> for r in response:
>
>//Do something with response
>
>
> However, this seems to be a blocking call and like i said the server 
> rarely responds. What can i look at from a grpc level to get delivery 
> status?
>
> Thanks
> Sudharsan
>
>
>
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/e58be813-276e-4f09-bbc6-1927a446180bn%40googlegroups.com.

Re: [grpc-io] In gRPC c++, is there a way to get notified when the peer gets disconnected?

[Thomas Mercier]

There is currently some sort of intermittent bug related to that API:
https://github.com/grpc/grpc/issues/18929

On Wed, Aug 12, 2020 at 11:31 AM 'apo...@google.com' via grpc.io <
grpc-io@googlegroups.com> wrote:

> If you're using the async completion queue based C++ API, then I believe
> you can use the AsyncNotifyWhenDone
> 
>  API
> for this. See surrounding comments in the linked code for more details.
>
> On Wednesday, August 12, 2020 at 8:00:42 AM UTC-7 mjp...@indeed.com wrote:
>
>> Health Checking Protocol:
>> https://grpc.github.io/grpc/cpp/md_doc_health-checking.html
>>
>> On Wed, Aug 12, 2020 at 9:59 AM Mya Pitzeruse  wrote:
>>
>>> Let's start with the server case because it's a bit easier. gRPC
>>> provides some built in healthchecking capabilities. Clients watch server
>>> health. When a server goes unhealthy, clients remove them from the pool.
>>>
>>> gRPC doesn't necessarily surface connection primitives to your server
>>> side so it's probably not easy to get at the same information for clients.
>>> On the other hand, you could use something like a long lived bidi-streaming
>>> API to "simulate" a connection with a backend. You'll need to handle
>>> network disconnects, but you could use that approach to do some cleanup.
>>> While it's not C++, here's a go example where a server side streaming API 
>>> cleans
>>> up a subscription
>>> 
>>> when the client is disconnected.
>>>
>>>
>>> On Wed, Aug 12, 2020 at 5:57 AM Sachin Bharadwaj S <
>>> ssachinb...@gmail.com> wrote:
>>>
 I have implemented a gRPC server application and multiple clients can
 connect to it and call RPCs.

 In the cases of client disconnection or client restarts, I would want
 to know which client got disconnected so that I can do some cleanup
 corresponding to that client.

 Similarly, if the server goes down, how can the client get notified?

 Does gRPC c++ stack provides a notification/callback to the
 application? If not, what is the best way to handle the connection
 termination on either side?

 --
 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 grpc-io+u...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/grpc-io/ab98d62c-231b-4e5b-bc0e-6519a9d0320ao%40googlegroups.com
 
 .

>>>
>>>
>>> --
>>>
>>> Mya Pitzeruse
>>>
>>> Principal Software Engineer - Service Infrastructure
>>>
>>> Gender Pronouns: She, Her, Hers
>>>
>>> mjp...@indeed.com
>>>
>>>
>>> Indeed - We help people get jobs.
>>>
>>> Indeed.com 
>>>
>>> Facebook   |  Twitter
>>>   |  Instagram
>>> 
>>>
>>
>>
>> --
>>
>> Mya Pitzeruse
>>
>> Principal Software Engineer - Service Infrastructure
>>
>> Gender Pronouns: She, Her, Hers
>>
>> mjp...@indeed.com
>>
>>
>> Indeed - We help people get jobs.
>>
>> Indeed.com 
>>
>> Facebook   |  Twitter
>>   |  Instagram
>> 
>>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/3141465f-6956-47d3-8a62-dc8ed81b92aen%40googlegroups.com
> 
> .
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CACV55uw8wkXO5Zbvx8-%3DnphQAbYr8Uh180xFC%2B89T1akRRx1-g%40mail.gmail.com.

Re: [grpc-io] In gRPC c++, is there a way to get notified when the peer gets disconnected?

['apo...@google.com' via grpc.io]

If you're using the async completion queue based C++ API, then I believe 
you can use the AsyncNotifyWhenDone 

 API 
for this. See surrounding comments in the linked code for more details.

On Wednesday, August 12, 2020 at 8:00:42 AM UTC-7 mjp...@indeed.com wrote:

> Health Checking Protocol: 
> https://grpc.github.io/grpc/cpp/md_doc_health-checking.html
>
> On Wed, Aug 12, 2020 at 9:59 AM Mya Pitzeruse  wrote:
>
>> Let's start with the server case because it's a bit easier. gRPC provides 
>> some built in healthchecking capabilities. Clients watch server health. 
>> When a server goes unhealthy, clients remove them from the pool.
>>
>> gRPC doesn't necessarily surface connection primitives to your server 
>> side so it's probably not easy to get at the same information for clients. 
>> On the other hand, you could use something like a long lived bidi-streaming 
>> API to "simulate" a connection with a backend. You'll need to handle 
>> network disconnects, but you could use that approach to do some cleanup. 
>> While it's not C++, here's a go example where a server side streaming API 
>> cleans 
>> up a subscription 
>> 
>>  
>> when the client is disconnected.
>>
>>
>> On Wed, Aug 12, 2020 at 5:57 AM Sachin Bharadwaj S  
>> wrote:
>>
>>> I have implemented a gRPC server application and multiple clients can 
>>> connect to it and call RPCs.
>>>
>>> In the cases of client disconnection or client restarts, I would want to 
>>> know which client got disconnected so that I can do some cleanup 
>>> corresponding to that client.
>>>
>>> Similarly, if the server goes down, how can the client get notified?
>>>
>>> Does gRPC c++ stack provides a notification/callback to the application? 
>>> If not, what is the best way to handle the connection termination on either 
>>> side?
>>>
>>> -- 
>>> 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 grpc-io+u...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/grpc-io/ab98d62c-231b-4e5b-bc0e-6519a9d0320ao%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>
>>
>> -- 
>>
>> Mya Pitzeruse
>>
>> Principal Software Engineer - Service Infrastructure
>>
>> Gender Pronouns: She, Her, Hers
>>
>> mjp...@indeed.com
>>
>>
>> Indeed - We help people get jobs.
>>
>> Indeed.com 
>>
>> Facebook   |  Twitter 
>>   |  Instagram 
>> 
>>
>
>
> -- 
>
> Mya Pitzeruse
>
> Principal Software Engineer - Service Infrastructure
>
> Gender Pronouns: She, Her, Hers
>
> mjp...@indeed.com
>
>
> Indeed - We help people get jobs.
>
> Indeed.com 
>
> Facebook   |  Twitter 
>   |  Instagram 
> 
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/3141465f-6956-47d3-8a62-dc8ed81b92aen%40googlegroups.com.

[grpc-io] Re: Failed to start grpc server on QNX grpc_combiner_continue_exec_ctx () at grpc_core::ExecCtx::Get()->combiner_data()->active_combiner

['apo...@google.com' via grpc.io]

There is a similar conversation in https://github.com/grpc/grpc/issues/23714 
with 
more context -- is this the same issue?

On Thursday, August 6, 2020 at 10:11:34 PM UTC-7 belanke...@gmail.com wrote:

> My code is as simple as below:
>
> std::string serverAddr =
>   qaic::qmonInetAll + ":" + std::to_string(config.port);
>
>   GRPCService service;
>   MonitorService::Service *monitorService = 
>   ServiceExt::Service *monitorExtService = 
>
>   service.init();
>
>   ServerBuilder builder;
>   builder.AddListeningPort(serverAddr, grpc::InsecureServerCredentials());
>   
>   notification_queue_ = builder.AddCompletionQueue();
>   client_queue_ = builder.AddCompletionQueue();
>   
>   builder.RegisterService(monitorService);
>   builder.RegisterService(monitorExtService);
>   builder.RegisterService(_);
>
>   server_ = builder.BuildAndStart();
>   LogInfoG("Server listening on {}", serverAddr);
>
>   // Queue a connect wait request
>   initClientSink();
>
>   // start 2 threads for receiving messages.
>   clientConnectThread_ =
>   std::thread(::startClientConnectThread, this);
>   notificationThread_ =
>   std::thread(::startNotificationThread, this);
>   if (asyncTestSupport) {
> type2MsgGenThread_ =
> std::thread(::genType2Messages, this);
>   }
>
>   readyStatus.set_value(QS_SUCCESS);
>
>   server_->Wait();
>   // Kill threads and wait for them to exit
>   notification_queue_->Shutdown();
>   client_queue_->Shutdown();
>   // The threads should exit once a trycancel is called
>   // on every client
>   clientConnectThread_.join();
>   notificationThread_.join();
>
>
> Let me know if I code is correct.
>

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/d88f583c-a2e9-4a75-b8cc-f169f5ed6f2dn%40googlegroups.com.

[grpc-io] Study On Rejected Refactorings

[jevgenija]

Dear grpc developers,

As part of a research team from Università della Svizzera italiana 
(Switzerland) and University of Sannio (Italy), we have analyzed 
refactoring pull requests in grpc/grpc-java repository and are looking for 
developers for a short 5-10 min survey 
(https://usi.eu.qualtrics.com/jfe/form/SV_cO6Ayah0D6q4eSF). Would you 
please spare your time by answering some questions about 
refactoring-related contributions? We would greatly appreciate your input — 
it would help us understand how developers can improve the quality of 
refactoring contributions, and benefit the development process. The 
responses will be anonymized and handled confidentially! Thank you a lot!

If you consider this message to be spam, I'm very sorry! There will be no 
follow-up to bother you.

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/545b1712-2f40-4ac3-94f2-0b326de5a1cfo%40googlegroups.com.

Re: [grpc-io] Building a grpc reverse proxy using client headers

['Eric Anderson' via grpc.io]

Using a gRPC-based proxy to provide your own logic sounds good and fine.
Since you just need headers you could make your own HTTP/2 proxy, but
there's nothing wrong with using gRPC as the proxy in my mind.

On Thu, Aug 6, 2020 at 1:47 PM  wrote:

> I couldn't find a lot of documentation on how the client and server in
> gRPC internally talk to each other and what are the best practices when
> writing your own ServerCallHandler, ClientCall.Listener and
> ServerCall.Listener; particularly a sequence diagram of how startCall(),
> onMessage(), onHalfClose(), onCancel() and onReady() are called and what
> are the guarantees gRPC provides.
>

All of that documentation should be in the respective
class's documentation. You probably want to look at the ClientCall and
ServerCall classes first. The ClientCall.Listener sort of mirrors
ServerCall and the ServerCall.Listener mirrors ClinetCall.

You may find https://github.com/grpc/grpc/pull/15460 helpful. It is
basically the documentation that already exists in Java, but reworded a
bit. It isn't merged because of nomenclature reasons; it is pretty
accurate, just the precise names we use were in debate.

I would like to know if my approach to tackle the requirement sounds
> acceptable and whether there are things that I should take into
> consideration when building this solution. One thing for example is that
> the clients will have to create a new stub for each request to add custom
> headers before starting a call. Is this good or bad? I don't see any
> problem with it in terms of how gRPC works but would like to know if it
> will break something I'm not aware about.
>

It's not bad at all. I assume you're saying you'd use
stub.withInterceptors() which would return a new stub. That's no issue.
Stubs are cheap.

You do have another option though: you could have an interceptor that will
manage the header always present in the stub and provide it configuration
via stub.withOption(). withOption() also creates a stub. The only
difference is that you can expose a higher-level API via the
CallOptions.Key instead of directly modifying the Metadata at each call
site. This doesn't matter if there's only a few call sites sending RPCs.
But if you end up having many you may find it advantageous.

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oNSKu%2B6cpQqpzKdDo%3Dzcm0%2BjpF9JGwYuHVsTd6ciTRvhQ%40mail.gmail.com.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Uniquely identifying clients in gRPC c++

['Mya Pitzeruse' via grpc.io]

You can generate a UUID in code, but that will only be valid for the length
of deployment. This could be passed in as an option to your client. The
best way to identify clients and do it securely is using mTLS (which gRPC
does support).

On Wed, Aug 12, 2020 at 6:28 AM Sachin Bharadwaj S <
ssachinbharad...@gmail.com> wrote:

>
> I am implementing gRPC server application and multiple clients are
> connected to my server and starts to call RPCs.
>
>
> How can the server uniquely identify which client is calling the RPC?
>
>
> Let us assume that server exposes a register RPC and client is implemented
> in such a way that it calls the register API only once and at the start of
> the client.
>
>
> Let us also assume that the server guarantees to generate and assign a
> unique ID for each client in the register RPC.
>
>
> For example,
>
> Client A -> ID=1
>
> Client B -> ID=2
>
>
> Is there a way to get back the ID associated with the client when an RPC
> is called?
>
>
> We do not want to send the ID to the client and ask the client to send the
> same ID in all the further RPCs which leads to change in the .proto file.
>
> How can this be handled in gRPC?
>
>
> Can I keep this sticky ID somewhere in the context and get back in all the
> RPC associated with the same client?
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/d77ee459-64c8-4730-836d-670878d63948o%40googlegroups.com
> 
> .
>


-- 

Mya Pitzeruse

Principal Software Engineer - Service Infrastructure

Gender Pronouns: She, Her, Hers

mjp...@indeed.com


Indeed - We help people get jobs.

Indeed.com 

Facebook   |  Twitter
  |  Instagram


-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAHa8AVROwfxycc3KOFsXaCc_bggtpfdEru6f%2B0Uo2wK5FudEzQ%40mail.gmail.com.

Re: [grpc-io] In gRPC c++, is there a way to get notified when the peer gets disconnected?

['Mya Pitzeruse' via grpc.io]

Health Checking Protocol:
https://grpc.github.io/grpc/cpp/md_doc_health-checking.html

On Wed, Aug 12, 2020 at 9:59 AM Mya Pitzeruse  wrote:

> Let's start with the server case because it's a bit easier. gRPC provides
> some built in healthchecking capabilities. Clients watch server health.
> When a server goes unhealthy, clients remove them from the pool.
>
> gRPC doesn't necessarily surface connection primitives to your server side
> so it's probably not easy to get at the same information for clients. On
> the other hand, you could use something like a long lived bidi-streaming
> API to "simulate" a connection with a backend. You'll need to handle
> network disconnects, but you could use that approach to do some cleanup.
> While it's not C++, here's a go example where a server side streaming API 
> cleans
> up a subscription
> 
> when the client is disconnected.
>
>
> On Wed, Aug 12, 2020 at 5:57 AM Sachin Bharadwaj S <
> ssachinbharad...@gmail.com> wrote:
>
>> I have implemented a gRPC server application and multiple clients can
>> connect to it and call RPCs.
>>
>> In the cases of client disconnection or client restarts, I would want to
>> know which client got disconnected so that I can do some cleanup
>> corresponding to that client.
>>
>> Similarly, if the server goes down, how can the client get notified?
>>
>> Does gRPC c++ stack provides a notification/callback to the application?
>> If not, what is the best way to handle the connection termination on either
>> side?
>>
>> --
>> 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 grpc-io+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/grpc-io/ab98d62c-231b-4e5b-bc0e-6519a9d0320ao%40googlegroups.com
>> 
>> .
>>
>
>
> --
>
> Mya Pitzeruse
>
> Principal Software Engineer - Service Infrastructure
>
> Gender Pronouns: She, Her, Hers
>
> mjp...@indeed.com
>
>
> Indeed - We help people get jobs.
>
> Indeed.com 
>
> Facebook   |  Twitter
>   |  Instagram
> 
>


-- 

Mya Pitzeruse

Principal Software Engineer - Service Infrastructure

Gender Pronouns: She, Her, Hers

mjp...@indeed.com


Indeed - We help people get jobs.

Indeed.com 

Facebook   |  Twitter
  |  Instagram


-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAHa8AVTsVqGoxKk3s_bOJaQLDiXCQi6BaDUgdcKWJEtJQ-DTZw%40mail.gmail.com.

Re: [grpc-io] In gRPC c++, is there a way to get notified when the peer gets disconnected?

['Mya Pitzeruse' via grpc.io]

Let's start with the server case because it's a bit easier. gRPC provides
some built in healthchecking capabilities. Clients watch server health.
When a server goes unhealthy, clients remove them from the pool.

gRPC doesn't necessarily surface connection primitives to your server side
so it's probably not easy to get at the same information for clients. On
the other hand, you could use something like a long lived bidi-streaming
API to "simulate" a connection with a backend. You'll need to handle
network disconnects, but you could use that approach to do some cleanup.
While it's not C++, here's a go example where a server side streaming
API cleans
up a subscription

when the client is disconnected.


On Wed, Aug 12, 2020 at 5:57 AM Sachin Bharadwaj S <
ssachinbharad...@gmail.com> wrote:

> I have implemented a gRPC server application and multiple clients can
> connect to it and call RPCs.
>
> In the cases of client disconnection or client restarts, I would want to
> know which client got disconnected so that I can do some cleanup
> corresponding to that client.
>
> Similarly, if the server goes down, how can the client get notified?
>
> Does gRPC c++ stack provides a notification/callback to the application?
> If not, what is the best way to handle the connection termination on either
> side?
>
> --
> 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 grpc-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/ab98d62c-231b-4e5b-bc0e-6519a9d0320ao%40googlegroups.com
> 
> .
>


-- 

Mya Pitzeruse

Principal Software Engineer - Service Infrastructure

Gender Pronouns: She, Her, Hers

mjp...@indeed.com


Indeed - We help people get jobs.

Indeed.com 

Facebook   |  Twitter
  |  Instagram


-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAHa8AVSGvakLke_a5Yudr-GJZGMcsuVsT7TJdrwt-1wHRbvgvQ%40mail.gmail.com.

[grpc-io] Uniquely identifying clients in gRPC c++

[Sachin Bharadwaj S]

I am implementing gRPC server application and multiple clients are 
connected to my server and starts to call RPCs.


How can the server uniquely identify which client is calling the RPC?


Let us assume that server exposes a register RPC and client is implemented 
in such a way that it calls the register API only once and at the start of 
the client.


Let us also assume that the server guarantees to generate and assign a 
unique ID for each client in the register RPC.


For example,

Client A -> ID=1

Client B -> ID=2


Is there a way to get back the ID associated with the client when an RPC is 
called?


We do not want to send the ID to the client and ask the client to send the 
same ID in all the further RPCs which leads to change in the .proto file.

How can this be handled in gRPC?


Can I keep this sticky ID somewhere in the context and get back in all the 
RPC associated with the same client?

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/d77ee459-64c8-4730-836d-670878d63948o%40googlegroups.com.

[grpc-io] In gRPC c++, is there a way to get notified when the peer gets disconnected?

[Sachin Bharadwaj S]

I have implemented a gRPC server application and multiple clients can 
connect to it and call RPCs.

In the cases of client disconnection or client restarts, I would want to 
know which client got disconnected so that I can do some cleanup 
corresponding to that client.

Similarly, if the server goes down, how can the client get notified?

Does gRPC c++ stack provides a notification/callback to the application? If 
not, what is the best way to handle the connection termination on either 
side?

-- 
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 grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/ab98d62c-231b-4e5b-bc0e-6519a9d0320ao%40googlegroups.com.