One client many servers

[Fabiano Ferronato]

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.

 

[Piotr Morgwai Kotarbinski]

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!

[Fabiano Ferronato]

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

[Yuri Golobokov]

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.

[Fabiano Ferronato]

Hi Yuri, thanks for the reply! 

Can you execute remote calls from the server to the clients with this approach? 

The main spec for me is having the ability to execute code in all devices connected to the PC.

[Yuri Golobokov]

Sure, within a bi-directional streaming call any peer can send messages any time.

https://grpc.io/docs/what-is-grpc/core-concepts/#bidirectional-streaming-rpc

"Client- and server-side stream processing is application specific. Since the two streams are independent, the client and server can read and write messages in any order."

Notice that on a client side you should expect different network/connectivity issues and code your client in a way that it will restart the bidi streaming call if it was terminated.

--
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/E2d-c4Xusls/unsubscribe.
To unsubscribe from this group and all its topics, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/8b58cfee-eacf-4b70-b5d3-64d5b4981f89n%40googlegroups.com.

[Eberhard Ludwig]

In case you decide for streaming interface.

As far as I know, for a streaming interface, you define one message type, which you can then send multiple times. But it is not possible to send different kind of messages to the peer over one streaming interface.

If you want to send only one type of message, then the streaming interface is good enough.

If you plan to have a real bi-directional message exchange, then it is worth to look for another technology.

I tried finalmq, this looks quite promising.

Cheers

Eberhard

[Yuri Golobokov]

One option is to include (or wrap) different kinds of messages in a oneof field of the message used in the streaming rpc.

For example,

service AbcService {

  rpc StreamingCommunication(stream StreamMessage) returns (stream StreamMessage) {}

}

message StreamMessage {

  oneof message {

    CreateAction create_action = 1

    UpdateAction update_action = 2

    ...

  }

}

--

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/E2d-c4Xusls/unsubscribe.
To unsubscribe from this group and all its topics, send an email to grpc-io+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/6298a2b5-f2cb-4420-8335-d5bf569eefafn%40googlegroups.com.

[Richard Belleville]

> In case you decide for streaming interface.

> As far as I know, for a streaming interface, you define one message type, which you can then send multiple times. But it is not possible to send different kind of messages to the peer over one streaming interface.

> If you want to send only one type of message, then the streaming interface is good enough.

This is not true. Suppose you want to send either FooMsg or BarMsg as a request msg, then just do this:

message RequestMsg {

  oneof {

    FooMsg foo = 1;

    BarMsg bar = 2;

[Eberhard Ludwig]

Thank you for the idea. I have not thought about oneof.

btw., I just started evaluating finalmq. It supports plain TCP, HTTP and also mqtt together with protobuf and json. A browser can directly connect to the application and can call the services. Also the communication via a mqtt broker is possible.

A server can send events or requests to clients without needing an open request from the client (at least the timer example looks very easy to me). I was suprised, that it is even possible to call a service with plain TCP/telnet like this:
/<servicename>/<messagename>!<correlationID>{jsondata}
Today, I will evaluate the performance.