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/CAAcqB%2Bt97%3DxJvwUgb_4k0aPw8g_VkiV47Tx2rksXPp%2BceOCUOQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
