Server side connection management

[Arpit Baldeva]

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. 

[Spencer Fang]

Your reading is correct, the idle manager checks for the case where there are no active RPCs (including long lived streaming RPCs). The StreamTracer provides a way to check the last time a message was sent or received on a per RPC basis, but unfortunately there's no connection level aggregation at the moment.

--
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 grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
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/91a74931-3580-4e9f-a9d2-1bcd3b743818%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Spencer Fang

[rav...@gmail.com]

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

[Arpit Baldeva]

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.

--
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 grpc-io+unsubscribe@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.
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.

[Ravi Jonnadula]

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. 

[Arpit Baldeva]

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 <abal...@gmail.com> 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, <rav...@gmail.com> 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 grpc-io+u...@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.

[Ravi Jonnadula]

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.

To unsubscribe from this group and all its topics, send an email to grpc-io+unsubscribe@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.
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.

[Spencer Fang]

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.

--

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 grpc-io+unsubscribe@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.
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/CAC-L5hLX%3DfmHZLSPH%2BXbbF9kM_w7ke%3Dh83XeUvybvC-iMvwd7w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Spencer Fang

[Spencer Fang]

Correction: io.grpc.Grpc.TRANSPORT_ATTR_REMOTE_ADDR is an Attributes.Key

--

Spencer Fang

[Ravi Jonnadula]

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.

[Spencer Fang]

+meng...@google.com, who works on grpc-go

--

Spencer Fang

[Menghan Li]

Ravi,

In go, the client address is part of the peer struct in the RPC context (https://godoc.org/google.golang.org/grpc/peer#Peer).

Use https://godoc.org/google.golang.org/grpc/peer#FromContext to get peer out from the context.

Thanks,

Menghan

[Arpit Baldeva]

Client IP is not a reliable way to keep track of client. For example, you could have many clients sitting behind a proxy and they will share the ip address. I only use it for logging purpose. So depends on your use case.

--

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 grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
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/7f7797bb-3970-4b62-8e5a-eaa7e8f13e18%40googlegroups.com.

[Ravi Jonnadula]

Good point Arpit, agreed, when there is a proxy.

Thanks Menghan, et all for your help.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAL2p%3D0k3yRy0BW%2Bwx9RMa8n6FQLH9m5zT8tVQUf5x3wkfKW51Q%40mail.gmail.com.