It just depends on your application. From what I can tell based on your description, you have a single rpc executing between client and server. If you have many rpcs exposed, you wouldn't want to run a 'clean up' for each onDone call.
Also, by "ungraceful disconnect", I also include any situation that results in an absence of communication between client and server (for example, if a cable is pulled on one of them, it might take a while for the other machine to notice this). Some applications may only want to detect client state at server or server state at client or both. They may also want to know the state 'on demand'. So all these can be accomplished with a 'heartbeat rpc' per client depending on the need of a specific application. Frameworks I have worked in the past expose the actual socket/client connection which can make this particular case slightly easier. Grpc hides network layer (and rightly so) so it just needs a bit of additional work to accomplish but can be done. Thanks. On Thu, Aug 31, 2017 at 12:17 AM, <[email protected]> wrote: > Just to add, this is the context.Done() solution that I tried: > https://groups.google.com/d/msg/grpc-io/C0rAhtCUhSs/SzFDLGqiCgAJ > > > On Thursday, August 31, 2017 at 12:09:01 PM UTC+5, [email protected] > wrote: >> >> Is listening on the context.Done() channel in Go (on the server) >> sufficient? I ran a client and server locally with a client listening on a >> server->client stream, killed the client process, and saw that >> context.Done() was indeed called on the server. >> >> I'm assuming that killing a client process is what some of you are >> referring to as an "ungraceful exit". Under what scenario would listening >> on context.Done() not work? >> >> As of now I'm happy to listen on context.Done() and implement a heartbeat >> RPC, but am curious to know when context.Done() will fail. >> >> >> On Thursday, August 31, 2017 at 2:59:10 AM UTC+5, Arpit Baldeva wrote: >>> >>> >>Like I suggested before, why not send a "Going away" message just >>> before disconnect? >>> I am not sure when/what context you made that suggestion. >>> >>> Anyhow, "Going away" message is good for graceful close. For ungraceful >>> exits, a heartbeat rpc is the way to go in gRPC. That rpc can be >>> implemented in a specific fashion that the application needs. To clarify, >>> yes, I agree, this isn't something gRPC can do for the application. >>> >>> On Wed, Aug 30, 2017 at 2:08 PM, Carl Mastrangelo <[email protected]> >>> wrote: >>> >>>> The short answer is that you can't tell when a connection has gone >>>> away. Even gRPC can't really be sure when a connection is gone (we can >>>> guess). Like I suggested before, why not send a "Going away" message just >>>> before disconnect? This is the same solution that HTTP/2 uses under the >>>> hood (called "go away"). >>>> >>>> On Wed, Aug 30, 2017 at 2:03 PM, Arpit Baldeva <[email protected]> >>>> wrote: >>>> >>>>> I think most people asking this question are interested in knowing >>>>> whether a particular client/user is dead. The keepalive stuff is useful >>>>> for >>>>> grpc to internally manage the network resources clean up. However, as the >>>>> network layer is hidden, anybody who wants to detect the state of a >>>>> particular client has to do it at their application code level (say by >>>>> implementing a a streaming rpc and using heartbeat mechanism). >>>>> >>>>> On Wed, Aug 30, 2017 at 10:47 AM, 'Mahak Mukhi' via grpc.io < >>>>> [email protected]> wrote: >>>>> >>>>>> https://github.com/grpc/grpc-go/blob/master/keepalive/keepalive.go >>>>>> >>>>>> On Wed, Aug 30, 2017 at 1:46 AM, <[email protected]> wrote: >>>>>> >>>>>>> Was this ever implemented? Specifically, a way for grpc-go to detect >>>>>>> if a client is disconnected from a server->client stream? Can't find it >>>>>>> on >>>>>>> the grpc-go repo... >>>>>>> >>>>>>> >>>>>>> On Wednesday, March 8, 2017 at 5:03:42 AM UTC+5, [email protected] >>>>>>> wrote: >>>>>>>> >>>>>>>> We are working on providing a solution for such a case: If the >>>>>>>> other side of the connection becomes unresponsive due to some reason >>>>>>>> the >>>>>>>> connection is closed and the any stream(RPC) reading on it will get an >>>>>>>> error that the connection was closed. >>>>>>>> For the chat application, I'm assuming a streaming RPC would be >>>>>>>> established between server and client and each side must have a routine >>>>>>>> reading on this stream. In case of a connection error this reading >>>>>>>> routine >>>>>>>> will get an error. >>>>>>>> We're calling this mechanism a point-to-point healthcheck. The >>>>>>>> client-side work is done and the server-side is underway. >>>>>>>> >>>>>>>> >>>>>>>> On Friday, March 3, 2017 at 9:21:41 AM UTC-8, Arpit Baldeva wrote: >>>>>>>>> >>>>>>>>> For Go, this thread claimed that something like this would be >>>>>>>>> available in Q1 2017 - https://groups.google.com/fo >>>>>>>>> rum/#!topic/grpc-io/C0rAhtCUhSs >>>>>>>>> >>>>>>>>> Regardless of the language (I am working with C++ impl), my plan >>>>>>>>> to implement this functionality is also RPC based (streaming Ping >>>>>>>>> rpc). On >>>>>>>>> server side, you can detect the client disconnection via >>>>>>>>> AsyncNotifyWhenDone as discussed here ( >>>>>>>>> https://github.com/grpc/grpc/issues/3956 ) >>>>>>>>> >>>>>>>>> On Thursday, March 2, 2017 at 9:33:48 PM UTC-8, Carl Mastrangelo >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> I'm actually more familiar with Java, though the architectures >>>>>>>>>> aren't that different. Most of gRPC is centered around the Call, >>>>>>>>>> rather >>>>>>>>>> than the Connection. If it were me, I would make a custom RPC that >>>>>>>>>> implies >>>>>>>>>> "Disconnecting". This would also allow you to embellish the >>>>>>>>>> disconnect >>>>>>>>>> (like add a going away message). If you really care about the >>>>>>>>>> connection >>>>>>>>>> dropping, at least in Java, you can tell by installing a >>>>>>>>>> ServerTransportFilter and checking onTerminated, thought this >>>>>>>>>> doesn't help >>>>>>>>>> with your Go program. I'll let someone else speak for that. Still >>>>>>>>>> though, >>>>>>>>>> my personal take is to use an RPC to implement it. >>>>>>>>>> >>>>>>>>>> On Thursday, March 2, 2017 at 2:33:21 AM UTC-8, Gustavo García >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Carl, Thank you for your answer. >>>>>>>>>>> >>>>>>>>>>> This is a chat application, so when a user disconnects you want >>>>>>>>>>> to tell everybody else in the room that somebody left. That's >>>>>>>>>>> why I need >>>>>>>>>>> to detect it. Does it makes sense? >>>>>>>>>>> >>>>>>>>>>> If I turn on keep-alives, how would I detect the connection drop >>>>>>>>>>> in a GRPC Go server? (or other language if there is any limitation >>>>>>>>>>> in Go). >>>>>>>>>>> >>>>>>>>>>> Thx a loot >>>>>>>>>>> >>>>>>>>>>> El mié., 1 mar. 2017 a las 20:48, Carl Mastrangelo (< >>>>>>>>>>> [email protected]>) escribió: >>>>>>>>>>> >>>>>>>>>>>> You can't really tell if the client is accidentally >>>>>>>>>>>> disconnected, but you can find out with a few seconds by turning on >>>>>>>>>>>> keep-alives. But, for your question: why do you want to know? >>>>>>>>>>>> What >>>>>>>>>>>> different course of action would you take if you did know? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Friday, February 24, 2017 at 4:19:59 PM UTC-8, >>>>>>>>>>>> [email protected] wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> How can I detect in the server side when a client gets >>>>>>>>>>>>> disconnected? The typical use case could be a chat server where >>>>>>>>>>>>> you want >>>>>>>>>>>>> to notify other users when somebody leaves ungracefully. >>>>>>>>>>>>> >>>>>>>>>>>>> I haven't been able to find a clear answer to this question >>>>>>>>>>>>> yet. I'm using Go implementation. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to a topic in >>>>>> the Google Groups "grpc.io" group. >>>>>> To unsubscribe from this topic, visit https://groups.google.com/d/to >>>>>> pic/grpc-io/C9rTVKZqqp0/unsubscribe. >>>>>> To unsubscribe from this group and all its topics, 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/CAD6XTdesZi-fpzLFm >>>>>> J8Z_dyX9%2BW9-ccvbkPa_bVAuyVDCqU4XA%40mail.gmail.com >>>>>> <https://groups.google.com/d/msgid/grpc-io/CAD6XTdesZi-fpzLFmJ8Z_dyX9%2BW9-ccvbkPa_bVAuyVDCqU4XA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>> >>> -- > You received this message because you are subscribed to a topic in the > Google Groups "grpc.io" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/grpc-io/C9rTVKZqqp0/unsubscribe. > To unsubscribe from this group and all its topics, 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/36b01f54-f741-4bae-a6e3-90aa7d5b9cc7%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/36b01f54-f741-4bae-a6e3-90aa7d5b9cc7%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAL2p%3D0kvMSPWbevcKucUbr-5jrCnYVDE%3Dw9-VX_4dJERrg37xQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
