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_xPatzhOuJzMG64Hcr7XQ255V5JisH6Dj%2BQDZqHgw7uDw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
