What is a proper way to get a remote address in stream listener?

[gold.d...@gmail.com]

I just updated to 0.14.0 and now I can call call.attributes().get(ServerCall.REMOTE_ADDR_KEY) in ServerInterceptor. Do I have to use ThreadLocal to use this information in StreamListener?

[tsuna]

Funnily enough, I was about to write to the ML to ask a similar
question but about the Go API. I can’t find a proper way of getting
to the client’s IP address for a given stream. It seems to be stashed
in the context.Context object but with an unexported key
peer.peerKey{} and it’s also somewhere inside the (in the serverStream
struct there is a pointer to a transport.Stream object that has an
instance of a ServerTransport interface that has a RemoteAddr()
method, but these aren’t exported).

> --
> 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+u...@googlegroups.com.
> To post to this group, send email to grp...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/51d7d45f-0883-4622-b057-16f47a57b7bf%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Benoit "tsuna" Sigoure

[Kun Zhang]

What StreamListener are you talking about? Do you mean ServerCall.Listener?
It's safe to call call.attributes() from the ServerCall.Listener created from your ServerInterceptor.

[Qi Zhao]

Hi tsuna,

Here it is an example to get the peer info on the server:

https://github.com/grpc/grpc-go/blob/c962da7be9c620c4a19158d978d1bf995c480098/test/end2end_test.go#L138

On Mon, May 2, 2016 at 8:32 PM, tsuna <tsun...@gmail.com> wrote:

Funnily enough, I was about to write to the ML to ask a similar
question but about the Go API.  I can’t find a proper way of getting
to the client’s IP address for a given stream.  It seems to be stashed
in the context.Context object but with an unexported key
peer.peerKey{} and it’s also somewhere inside the (in the serverStream
struct there is a pointer to a transport.Stream object that has an
instance of a ServerTransport interface that has a RemoteAddr()
method, but these aren’t exported).

On Mon, May 2, 2016 at 6:23 PM,  <gold.d...@gmail.com> wrote:
> I just updated to 0.14.0 and now I can call
> call.attributes().get(ServerCall.REMOTE_ADDR_KEY) in ServerInterceptor. Do I
> have to use ThreadLocal to use this information in StreamListener?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/51d7d45f-0883-4622-b057-16f47a57b7bf%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
Benoit "tsuna" Sigoure

--
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.

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

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

--

Thanks,

-Qi

[Eric Anderson]

I think they're meaning StreamObserver. I probably answered your comment on StackOverflow:

The pattern we'd suggest is to have a single central "auth policy" interceptor that would access REMOTE_ADDR_KEY and then put an object on the Context (which Contexts.interceptCall() makes relatively easy)

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/38c39b64-a72c-4e6e-8603-b17d5add88e0%40googlegroups.com.

[gold.d...@gmail.com]

Thanks for a quick reply and sorry for a confusion. I'm fairly new to grpc and grpc java so I wasn't sure what it's called. I didn't know there is a context that you can use so I will change my code to have a single central "auth policy" interceptor.

On Wednesday, May 4, 2016 at 8:19:26 AM UTC+9, Eric Anderson wrote:

I think they're meaning StreamObserver. I probably answered your comment on StackOverflow:

The pattern we'd suggest is to have a single central "auth policy" interceptor that would access REMOTE_ADDR_KEY and then put an object on the Context (which Contexts.interceptCall() makes relatively easy)

On Tue, May 3, 2016 at 4:04 PM, 'Kun Zhang' via grpc.io <grp...@googlegroups.com> wrote:

What StreamListener are you talking about? Do you mean ServerCall.Listener?
It's safe to call call.attributes() from the ServerCall.Listener created from your ServerInterceptor.

On Monday, May 2, 2016 at 6:23:44 PM UTC-7, gold.d...@gmail.com wrote:

I just updated to 0.14.0 and now I can call call.attributes().get(ServerCall.REMOTE_ADDR_KEY) in ServerInterceptor. Do I have to use ThreadLocal to use this information in StreamListener?

--
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+u...@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.

[Eric Anderson]

On Tue, May 3, 2016 at 5:15 PM, <gold.d...@gmail.com> wrote:

I'm fairly new to grpc and grpc java so I wasn't sure what it's called. I didn't know there is a context that you can use so I will change my code to have a single central "auth policy" interceptor.

Context is fairly new (since maybe 0.12?). I know I didn't explain a lot in my response (interceptors, how to use Context), so if you have trouble implementing it please feel free to ask follow-up questions.

We've also not documented the "auth policy" pattern yet, so your question was a good one.

[tsuna]

On Tue, May 3, 2016 at 4:12 PM, Qi Zhao <zh...@google.com> wrote:
> Here it is an example to get the peer info on the server:
> https://github.com/grpc/grpc-go/blob/c962da7be9c620c4a19158d978d1bf995c480098/test/end2end_test.go#L138

Thank you!

--
Benoit "tsuna" Sigoure

[ela...@netflix.com]

Are there any plans to get the peer address on the client?

[Kun Zhang]

No, we don't have a plan yet. Because the server address is unknown when the call is started, the API would be different from the one with which you get the client address on the server. When and why do you need the peer address? 

[Eran Landau]

We're actually fine with getting the address after the call is started or more specifically at call completion (at least for unary calls).  We use the server address to gather information for tracing and metrics.  Our load balancer selects from hosts that could be in different EC2 zones and clusters (i.e. deployment stacks) or different versions of the services. 

[Kun Zhang]

Looks like it can be done through our stats/tracing framework, a.k.a. Census.

The Census team will soon opensource their API, on which gRPC will depend. Let me talk with them and see if the server address can also be recorded by Census.

[ooc...@gmail.com]

Why? I think Client can get the server address when the reponse back and the call finish？eg.onClose or onMessage

在 2016年5月25日星期三 UTC+8下午11:01:56，Kun Zhang写道：