Re: [grpc-io] viability of using gRPC to replace our existing RPC framework

[Arpit Baldeva]

Thanks for the response.

>>On server-side it should be exposed as a client cancellation.
Is that available in C++ implementation? I looked around and did not find 
it exposed. My further experiments show that in case a bi-directional 
stream is broken abruptly, the 'ok' bool on the AsyncNext call returns 
false.
NextStatus AsyncNext(void** tag, bool* ok, const T& deadline) 

If there is a better way to detect it, I'd be glad to know. 

>> add a MAX_CONNECTION_IDLE server-side configuration 
That's awesome! 

>>What connection metrics specifically? We've been adding some metric APIs 
in the various implementations recently.
I was mostly curious about what was already available. It'd nice to know 
the amount of sent/received bytes per peer. 

On Monday, December 5, 2016 at 3:40:41 PM UTC-8, Eric Anderson wrote:
>
> On Thu, Dec 1, 2016 at 3:40 PM, Arpit Baldeva  > wrote:
>
>> 1. *Detecting a dead client on server:* Is there a way or recommended 
>> mechanism to detect a client who is no longer connected to the server after 
>> an abrupt client shutdown? In our current framework, we get a TCP level 
>> disconnect which then ends the user session. But looking around the gRPC 
>> code base and searching past discussions in the group, the connection layer 
>> is hidden away and this information is not exposed. Detecting a dead client 
>> early is important in scenarios where client's state may be important to 
>> other clients. We have many use cases for it. For example, if two players 
>> are connected in a game session and one of them goes away, we'd like to 
>> update the status of that person on other client's machine.
>>
>
> We tend to use streams for this use-case. When gRPC learns of the 
> connection failure, any RPCs on that connection fail. Although note that a 
> single Channel can have multiple connections open underneath, so the 
> connection that failed may not be the one with the stream.
>
> I was wondering if I have a bi-directional streaming RPC for the sole 
>> purpose of detecting a disconnect, would I get any error on that stream in 
>> case of an abrupt client shutdown? It did not seem like that from the async 
>> interface though (async_stream.h).
>>
>
> Bi-di stream works great (although any streaming RPC can work). On 
> server-side it should be exposed as a client cancellation.
>
> 2. *Server side connection management:* Is there a doc that details the 
>> server side connection management? I am trying to figure out details like 
>> how long does a socket remain active for an inactive client? Is this a 
>> setting that can be customized?
>>
>
> I've been working on a design that would add a MAX_CONNECTION_IDLE 
> server-side configuration, which seems to fit what you're wanting. So it's 
> not there now, but it's coming.
>
> Are there any sort of connection metrics that are exposed to the 
>> application?
>>
>
> What connection metrics specifically? We've been adding some metric APIs 
> in the various implementations recently.
>

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/f53b1f14-638d-4214-9de8-cf06d015c22c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] viability of using gRPC to replace our existing RPC framework

['Eric Anderson' via grpc.io]

On Thu, Dec 1, 2016 at 3:40 PM, Arpit Baldeva  wrote:

> 1. *Detecting a dead client on server:* Is there a way or recommended
> mechanism to detect a client who is no longer connected to the server after
> an abrupt client shutdown? In our current framework, we get a TCP level
> disconnect which then ends the user session. But looking around the gRPC
> code base and searching past discussions in the group, the connection layer
> is hidden away and this information is not exposed. Detecting a dead client
> early is important in scenarios where client's state may be important to
> other clients. We have many use cases for it. For example, if two players
> are connected in a game session and one of them goes away, we'd like to
> update the status of that person on other client's machine.
>

We tend to use streams for this use-case. When gRPC learns of the
connection failure, any RPCs on that connection fail. Although note that a
single Channel can have multiple connections open underneath, so the
connection that failed may not be the one with the stream.

I was wondering if I have a bi-directional streaming RPC for the sole
> purpose of detecting a disconnect, would I get any error on that stream in
> case of an abrupt client shutdown? It did not seem like that from the async
> interface though (async_stream.h).
>

Bi-di stream works great (although any streaming RPC can work). On
server-side it should be exposed as a client cancellation.

2. *Server side connection management:* Is there a doc that details the
> server side connection management? I am trying to figure out details like
> how long does a socket remain active for an inactive client? Is this a
> setting that can be customized?
>

I've been working on a design that would add a MAX_CONNECTION_IDLE
server-side configuration, which seems to fit what you're wanting. So it's
not there now, but it's coming.

Are there any sort of connection metrics that are exposed to the
> application?
>

What connection metrics specifically? We've been adding some metric APIs in
the various implementations recently.

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oNAhpD88yL7Yuv0r6kr4Zk5f_YxxBFj9gh0AcFu%3DV8Xpw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] viability of using gRPC to replace our existing RPC framework

[Arpit Baldeva]

Hi,

I am investigating the viability of using gRPC (C++ version) to replace our 
existing RPC framework at Electronic Arts and would appreciate if somebody 
can provide me some answers in order for me to make the best judgement. For 
most of our existing usage, I have an idea of how to do that via gRPC. 
However, few questions remain.

1. *Detecting a dead client on server:* Is there a way or recommended 
mechanism to detect a client who is no longer connected to the server after 
an abrupt client shutdown? In our current framework, we get a TCP level 
disconnect which then ends the user session. But looking around the gRPC 
code base and searching past discussions in the group, the connection layer 
is hidden away and this information is not exposed. Detecting a dead client 
early is important in scenarios where client's state may be important to 
other clients. We have many use cases for it. For example, if two players 
are connected in a game session and one of them goes away, we'd like to 
update the status of that person on other client's machine. 

I was wondering if I have a bi-directional streaming RPC for the sole 
purpose of detecting a disconnect, would I get any error on that stream in 
case of an abrupt client shutdown? It did not seem like that from the async 
interface though (async_stream.h).

2. *Server side connection management:* Is there a doc that details the 
server side connection management? I am trying to figure out details like 
how long does a socket remain active for an inactive client? Is this a 
setting that can be customized? Are there any sort of connection metrics 
that are exposed to the application?

Appreciate your time.

Thanks
Arpit

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/62797b49-e2bb-4a98-8e5e-c34f0ee9c8a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.