Hi Fabiano, You can also consider another option: - On the PC side you can have a gRPC server - Each device will have a client that connects to the server (PC) and starts a bi-directional streaming call. - The first message on the streaming call can contain information about the device.
Pros: - No need to manage device addresses (endpoints). You'll need to have only the server address available on devices. - Devices can be behind the NAT/Proxy and still be able to connect to the server. On Wednesday, October 20, 2021 at 7:23:14 AM UTC-7 Fabiano Ferronato wrote: > Thanks a lot for your answer. > > Explaining better: > - The RPi devices actions are inter-dependent and will be coordinated by > the PC. e.g. dev2 will act only after dev1 replies. > - Independent parallel requests can also happen. e.g. dev1 and dev2 will > act independently. > - The subsequent requests can depend on the reply. e.g. If request to dev1 > is OK, send request to dev2. If not OK, abort. > - It should be "fast enough" to substitute a native application, where > logic and code execution runs in the same device. Nothing like real-time is > required tough. Anything around 10 ms ~ 100 ms should be enough. > > I guess the publish-subscribe system alternative should not apply in this > case. But the streaming looks like a good option! Thanks for pointing that. > > I'm thinking on the following: > > - On the PC side I have many coordinated gRPC clients; > - Each device (RPi) will have a server; > - Client1 send requests to Server1; > - Client2 send requests to Server2 etc. > > Please let me know your thoughts about it. > > Best Regards > Fabiano > > Em terça-feira, 19 de outubro de 2021 às 07:51:56 UTC+2, [email protected] > escreveu: > >> If all the function calls are unary, then It seems to me, it would be >> probably easier to use some existing publish-subscribe system, rather than >> a bare gRPC. >> In such a setup, each function would have its "requests topic", to which >> a caller (PC in your case) would publish request messages and subscribed >> devices would process it. Replies from the devices could be either sent to >> function's corresponding "replies topic' (actually for replies a queue may >> be better than a topic) to which the caller was subscribed, OR directly to >> the caller via an unary call (gRPC or other) with void return type. >> Alternatively there could be just 1 topic for all the functions and each >> request message would contain a function id and a "polymorphic" list of >> arguments specific to the given function. >> >> If some of the calls are streaming, then gRPC is probably still your best >> option, but it may depend how tightly request and reply streams are related >> (for example whether replies from devices will have an impact on the >> content of subsequent request messages and whether reply messages from a >> given device impact subsequent requests messages for this device only or >> for all devices). >> >> Cheers! >> >> On Monday, October 18, 2021 at 11:09:45 PM UTC+7 Fabiano Ferronato wrote: >> >>> I have a problem to solve: one computer (PC) will send requests to many >>> devices (e.g. RPi). The devices will execute the request and respond. >>> >>> Is it possible to use gRPC ? >>> >>> From the documentation (Introduction) it shows the opposite: clients >>> sending requests to a server. So maybe I'm going the wrong way choosing >>> gRPC. >>> >>> Any help is much appreciated. >>> >>> >>> >>> >> -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/16d37bc5-56ae-47e8-ad6a-b77eb6ca7289n%40googlegroups.com.
