I've been checking out the interceptor pattern. Tokens, certificates, metadata make sense to me. I'm confused about "the server decodes the token and associates the stream with the client". Once a client ID info in any way, it's unclear to me how the server associates a stream with a client and then when needed invokes a command on that particular stream.
I'm using go-lang. On Thu, Feb 8, 2018 at 2:35 PM, Carl Mastrangelo <[email protected]> wrote: > The client would need to self identify by setting a header when it > initiates the RPC. If you are using auth tokens, you could maybe put the > identity in the token. When the client makes an RPC, the server decodes > the token and associates the stream with the client. > > Another option (as mentioned in my first post) would be to use client side > certificates. When the server gets the RPC, it can determine the security > information from the connection and associate it with the stream. > > Lastly (and probably easiest) is to add the identity in a custom header > fields (also called "metadata"). You can do this directly with some gRPC > APIs and indirectly by making a client side RPC interceptor. I am more > familiar with Java, which favors the interceptor approach. It will depend > on what language of gRPC library you are using. > > > I would personally suggest the latter, since it is the most flexible, and > works well with proxies. It also and expandable, so you can put more info > in the headers to be identified by. > > > > On Thu, Feb 8, 2018 at 2:27 PM John Pearson <[email protected]> > wrote: > >> Makes sense, thanks for the explanation. I see tunneling is being worked >> on: https://github.com/grpc/grpc/issues/14101 >> >> Question: When I have 15 clients all connected in a bidirectional stream, >> how does the Server send a message to a particular client? For example in >> my case: Server needs to tell a client12 to run a particular command, how >> to identify the right connection/channel Server side? >> >> I've tried searching for this: >> - https://groups.google.com/forum/#!searchin/grpc-io/ >> identify$20stream/grpc-io/MAjt9cE_uCU/VMAjo_KiAQAJ >> - https://groups.google.com/forum/#!searchin/grpc-io/ >> identify$20stream/grpc-io/z6aEEiaeopM/AVSZRFPTCAAJ >> >> >> >> >> On Wed, Feb 7, 2018 at 1:18 PM, Carl Mastrangelo <[email protected]> >> wrote: >> >>> Your flow is correct. Is it RPC? I guess that's a more >>> philosophical, but I don't think there is anything wrong with it. >>> Streaming RPCs are already kind of weird anyway. >>> >>> A more pure solution would be something akin to tunneling, where a >>> client connects to a server, but then runs a gRPC server _on top of_ the >>> client connection allowing the actual server to make client-like requests. >>> This has been discussed before, but wasn't implemented due to time >>> constraints. gRPC is fairly young so more advanced use cases like this >>> don't have solutions yet. >>> >>> Note that even though the flow is reversed, you still get a lot of the >>> benefits of gRPC. The real client still can do intelligent fail over >>> across all your servers. You get all the stats and trace capabilities. >>> Lastly, gRPC is pretty fast! >>> >>> >>> On Wed, Feb 7, 2018 at 12:46 PM John Pearson <[email protected]> >>> wrote: >>> >>>> Got it. So this isn't considered bad form for RPC? Technically it isn't >>>> RPC? In my case: >>>> >>>> - Server implements rpc Link (stream UpLink) returns (stream DownLink) >>>> {} >>>> - Client initiates connection >>>> - Client waits for messages to come down from the server to be executed >>>> - Clients parses the strings/bytes streamed down and uses a case >>>> statement to execute commands >>>> >>>> On Wed, Feb 7, 2018 at 12:04 PM, Carl Mastrangelo <[email protected]> >>>> wrote: >>>> >>>>> Yes, that is correct. (It's bidirectional because the word "stream" >>>>> is in both the request (UpLink) and response (DownLink).) >>>>> >>>>> I mistakenly thought this was another thread (which I replied to >>>>> yesterday) which had almost the same issue. Take a look at >>>>> https://groups.google.com/d/msg/grpc-io/G4eYs1zNMjE/Yh2WJS7TBwAJ >>>>> where I describe how to do what you want. >>>>> >>>>> >>>>> On Wed, Feb 7, 2018 at 11:38 AM John Pearson <[email protected]> >>>>> wrote: >>>>> >>>>>> I'm unclear on what the last part means: "That's why that issue, >>>>>> (and my post), suggest treating the message as inverted requests and >>>>>> responses." >>>>>> >>>>>> Do you mean rpc Link (stream UpLink) returns (stream DownLink) {} ? >>>>>> With a bidirectional stream? >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 7, 2018 at 11:27 AM, 'Carl Mastrangelo' via grpc.io < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> It's unlikely that gRPC will be able to have servers initiate >>>>>>> connections / rpcs to clients. The initial headers need to be sent by >>>>>>> the >>>>>>> client to the server, and only the server can send trailers to indicate >>>>>>> the >>>>>>> RPC is done. But, after these two, the client and server are peers. >>>>>>> That's why that issue, (and my post), suggest treating the message as >>>>>>> inverted requests and responses. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Monday, February 5, 2018 at 8:55:46 PM UTC-8, John Pearson wrote: >>>>>>>> >>>>>>>> Question regarding bi-directional streaming: >>>>>>>> >>>>>>>> Is this issue(https://github.com/grpc/grpc-go/issues/484# >>>>>>>> issuecomment-288880402) solved because of bidirectional rpc? -- >>>>>>>> it is almost exactly the same as my use case. >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Feb 5, 2018 at 3:41 PM, 'Carl Mastrangelo' via grpc.io < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Sounds like you want to use a client streaming rpc. The client >>>>>>>>> will start an RPC, and periodically send messages to the server, >>>>>>>>> which will >>>>>>>>> never respond. This works well if the time between updates is small >>>>>>>>> perhaps no more than a minute apart. If it's longer, it would be >>>>>>>>> better >>>>>>>>> to just make it unary because the connection will be at risk of being >>>>>>>>> torn >>>>>>>>> down by intermediary things. >>>>>>>>> >>>>>>>>> If you trust the hardware you are running on, a common way of >>>>>>>>> authing would be client side certificates, but we leave the problem of >>>>>>>>> certificate rotation and revocation up to you. In gRPC, auth is more >>>>>>>>> commonly (always?) done at the RPC level. Each RPC would need an auth >>>>>>>>> token, like a JWT. >>>>>>>>> >>>>>>>>> If you want a command and control style system, you'll need to use >>>>>>>>> a bidirectional streaming RPC. This would let the client phone >>>>>>>>> home, and >>>>>>>>> wait for messages to come down from the server to be executed. The >>>>>>>>> client >>>>>>>>> must initiate the connection and the RPC, but after that each side is >>>>>>>>> a >>>>>>>>> peer. >>>>>>>>> >>>>>>>>> There are examples on how to do each style of these commands in >>>>>>>>> the github repos. Look for "Route Guide" examples on how to do it in >>>>>>>>> each >>>>>>>>> language. >>>>>>>>> >>>>>>>>> On Sunday, February 4, 2018 at 5:37:40 PM UTC-8, >>>>>>>>> [email protected] wrote: >>>>>>>>>> >>>>>>>>>> I manage a fleet of linux devices and I need a way to send >>>>>>>>>> telemetry data(CPU, memory, drives, etc.) from devices to a >>>>>>>>>> centralized >>>>>>>>>> server and also send commands(linux service restarts for example) >>>>>>>>>> from >>>>>>>>>> server to devices to execute on the device. The 15 different >>>>>>>>>> linux devices are bare metal boxes in 15 different locations access >>>>>>>>>> to WAN >>>>>>>>>> with a dynamic IP address. In a year the number of devices could >>>>>>>>>> jump to >>>>>>>>>> 100. >>>>>>>>>> >>>>>>>>>> I'm looking for suggestions on: >>>>>>>>>> - how to gather telemetry data to send to grpc server >>>>>>>>>> - how authenticate and identify devices >>>>>>>>>> - how to run commands locally on each device and report back >>>>>>>>>> >>>>>>>>>> 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/YB0HErGYZPw/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/66ed336c-6de9- >>>>>>>>> 4f80-b0e0-55b05338e45a%40googlegroups.com >>>>>>>>> <https://groups.google.com/d/msgid/grpc-io/66ed336c-6de9-4f80-b0e0-55b05338e45a%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/ >>>>>>> topic/grpc-io/YB0HErGYZPw/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/bc74b58e-8ae7- >>>>>>> 4538-9c95-e2fad7d66413%40googlegroups.com >>>>>>> <https://groups.google.com/d/msgid/grpc-io/bc74b58e-8ae7-4538-9c95-e2fad7d66413%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/CAKNtY_ykTQSnuCpoNWE7ZbCoOQdGDM-BF9Ww2qtZpHD5LxHZuA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
