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