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 <[email protected] 
> <javascript:>> 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 [email protected].
To post to this group, send email to [email protected].
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.

Reply via email to