3
votes

i'm having a little trouble trying to come to a solution and was wondering if someone could point me in the right direction.

I am implementing a system in which multiple clients are communicating with a server using gRpc. The service is written in golang and the clients are written in C.

I am trying to work out how to best handle communicating from the server to the client.

The options which i have considered so far are:

  1. Setup a server on each client
    • Considering there may be multiple clients operating from one external ip i'm not sure if it's possible to create a client listening to a combination of public ip, local ip and port ?
  2. Use bi-directional streaming
    • This seems like the wrong application of the above, will you have to spawn a new process just to hold open a connection ?
  3. Open a websocket alongside the gRpc service
    • I feel like this is not the right solution but seems to be the easiest out of the 3

I am also not completely confident as to the required work to implement each of the above in C as it seems alot of helper functionality isn't included in C

Update:

So i have implemented a solution using a go client + server. Making use of the bi-directional rpc stream,

Server

  • Create a chan for each client that connects and store it in a map on the service
  • Inside the stream method run a for
    • Check the chan for any messages and call stream.sen
    • Remove the client chan if stream.Context().Err()

Client

  • Create a channel for the messages coming back from the stream method
  • Start a goroutine calling stream.Recv on the stream service

Is this a reasonable approach to keep a connection open to the connected clients?

1

1 Answers

0
votes

About your choices:

  1. Setup a server on each client

I don't know you use case, but normally you can not require or guarantee that users can open listeners. The normal way is the client connect to the server and keep a channel opened.

  1. Use bi-directional streaming

gRPC can be used as streaming to receive Server Side Events(SSE). So this can be a good choice. https://docs.servicestack.net/server-events-grpc#streamserverevents

Is this a reasonable approach to keep a connection open to the connected clients?

I can't see anything wrong with this approach.

  1. Open a websocket alongside the gRpc service

Until now, I know no better solution to communicate events via http protocol other than WebSocket. It's very easy to implement, has a mature API based on events, supports text and binary data. From the development perspective you just need to worry about specific reverse proxy rules to ws or wss protocols.