[email protected], who works on grpc-go On Mon, Jan 8, 2018 at 4:17 PM, Ravi Jonnadula <[email protected]> wrote:
> Hi Spencer, > > Thanks for your response. this is exactly what I 'm looking for. > However, looks like this is available only in grpc-Java ... can't find it > in grpc-go ... > > Any equivalent in grpc-go? > > thanks. > > On Mon, Jan 8, 2018 at 2:19 PM, Spencer Fang <[email protected]> > wrote: > >> Correction: io.grpc.Grpc.TRANSPORT_ATTR_REMOTE_ADDR is an Attributes.Key >> >> On Mon, Jan 8, 2018 at 2:19 PM, Spencer Fang <[email protected]> >> wrote: >> >>> Ravi: >>> The client source IP/port information is present in the Attributes >>> object when the ServerCall is started, under the Metadata.Key >>> io.grpc.Grpc.TRANSPORT_ATTR_REMOTE_ADDR. You can stash away the >>> ServerCall when you server handler starts, or as a part of a >>> ServerInterceptor. But keep in mind that ServerCall is not synchronized, so >>> if you ever share it between threads you need to perform your own >>> synchronization. >>> >>> On Mon, Jan 8, 2018 at 2:03 PM, Ravi Jonnadula <[email protected]> wrote: >>> >>>> Is there any option to get the client source IP/port information from >>>> the context (without needing to explicitly encode it from the client side >>>> metadata)? >>>> >>>> thanks. >>>> >>>> On Mon, Jan 8, 2018 at 1:32 PM, Arpit Baldeva <[email protected]> >>>> wrote: >>>> >>>>> 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]> >>>>>> 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]> 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/pro >>>>>>>>> posal/blob/a339b01be9eafffb1adc4db8c782469caed18bdc/A9-serve >>>>>>>>> r-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]. >>>>>>>> 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/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 a topic in the >>>>> Google Groups "grpc.io" group. >>>>> To unsubscribe from this topic, visit https://groups.google.com/d/to >>>>> pic/grpc-io/g9oittuh_6c/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/468797ed-9c68-4fc4 >>>>> -a1c5-68f554acd297%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/grpc-io/468797ed-9c68-4fc4-a1c5-68f554acd297%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/ms >>>> gid/grpc-io/CAC-L5hLX%3DfmHZLSPH%2BXbbF9kM_w7ke%3Dh83XeUvybv >>>> C-iMvwd7w%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/grpc-io/CAC-L5hLX%3DfmHZLSPH%2BXbbF9kM_w7ke%3Dh83XeUvybvC-iMvwd7w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Spencer Fang >>> >> >> >> >> -- >> Spencer Fang >> > > -- Spencer Fang -- 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/CAK%3D-x_47usYZGG8P4bNFRN7t2vy9SCqZWLr2P9J7Qu7Cz-Mg5Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
