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

[Eric Anderson]

On Thu, Dec 1, 2016 at 3:40 PM, Arpit Baldeva <abal...@gmail.com> 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.

[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.