You can do this at your application level. Say your first rpc is "login" (or whatever you want it to be). You can create a "session" object in your application and return it some sort of "session-key" in the metadata. After that, your client must send that "session-key" in it's client context in future rpcs and one of that could be your server streaming notification rpc.
On Monday, January 8, 2018 at 12:39:06 PM UTC-8, Ravi Jonnadula wrote: > > In my case, once he client initiates first RPC message, I wanted to keep > the communication channel open between the server-clients. > The sever shall be able to send message to a specific client at some later > point of time through this RPC channel. > For that, I shall be able to maintain a list/map of clients active based > on the context information available. > With the information available from context.Conetext() I was not able to > distinguish different clients from the different/same remote. > > On Sat, Jan 6, 2018 at 1:42 PM Arpit Baldeva <[email protected] > <javascript:>> wrote: > >> My question was mainly around how to make sure the client network >> connection is cleaned up. I did end up with a simple mechanism to detect >> session inactivity and terminate you streaming rpcs at that point. If I get >> your question right, you just need to implement your notifications as a >> server streaming rpc per client/session. >> >> On Fri, Jan 5, 2018 at 5:54 PM, <[email protected] <javascript:>> wrote: >> >>> Hi Arpit, >>> >>> Did you get this working? >>> >>> I am looking for similar scenario where I have to keep the list of >>> client session information on the server side. >>> Based on someother event, I have to determine which client shall handle >>> this event and send message to that specific client. >>> >>> I don't seem to find these details from Context ... any help would be >>> great >>> >>> >>> On Tuesday, September 12, 2017 at 12:23:48 PM UTC-7, Arpit Baldeva wrote: >>>> >>>> Hi, >>>> >>>> After reading >>>> https://github.com/ejona86/proposal/blob/a339b01be9eafffb1adc4db8c782469caed18bdc/A9-server-side-conn-mgt.md >>>> >>>> , I am looking for a small clarification. >>>> >>>> It looks like the connections are not considered idle if they have >>>> outstanding rpcs. That would mean it includes server streaming rpcs as >>>> well, right? A common use case for server streaming rpcs is to allow for a >>>> Server to Client Notification system. This means application need to do >>>> "no >>>> rpc from client in some duration" detection as well in this scenario and >>>> finish streaming rpc before grpc library can run the network layer clean >>>> up >>>> on it's end? >>>> >>>> Thanks. >>>> >>> -- >>> 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/g9oittuh_6c/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected] <javascript:>. >>> To post to this group, send email to [email protected] >>> <javascript:>. >>> 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/77fd2acf-32a0-4452-86a1-ba6f97e782c4%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/grpc-io/77fd2acf-32a0-4452-86a1-ba6f97e782c4%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/468797ed-9c68-4fc4-a1c5-68f554acd297%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
