Notifications from server to client

[Julien]

Hello,

I have a server with several clients. From time to time, the server must send a notification to some clients.
I can’t find a proper way to do this. I had 2 different solutions to do that:

1.  Create an RPC function which returns a stream of notifications.
Something like:

rpc GetNotification(google.protobuf.Empty) returns (stream Notification) {}

The client would call this function “permanently” in a dedicated thread with the async interface:

stub->AsyncGetNotification(...)
...
while (!stopped) {
  nextStatus = completionQueue.AsyncNext(...);
  if (nextStatus == grpc::CompletionQueue::GOT_EVENT) {
    // handle the notification
    ...
  }
}

On the server side, the GetNotification function would just write the notification when there is no notification to send, and would do nothing the rest of the time.
But this means that there would be as many GetNotification functions executed at the same time as there are connected clients. I don’t expect to have much clients running at the same time (let’s say ~10-20), but I don’t like that much.

2.  Create a simple RPC function which returns a notification:

rpc GetNotification(google.protobuf.Empty) returns (Notification) {}

The client would call it periodically (let’s say every 5 seconds) and would handle the notification if there is one, and would do nothing if there is none.
On the server side, the GetNotification function would return an empty notification if there is none, or the notification with the appropriate data when needed.
I don’t like this solution much because it is not really efficient.

Is there a better solution than the two above ones?
Otherwise, which one is the best?

Thanks.

Julien

[Julien]

Any idea?
Any comment on this?

Thanks.

Julien

[Vijay Pai]

Hello,

The standard way to do this would be essentially your option 1, with some modifications. If you are using the async API, there is no need for a separate thread for the notifications; this can be done on the same completion queue as your regular activity as long as you use different tags for the different RPCs and their events. If you use the sync API, you should use a separate thread for the notification RPC. In fact, this is probably the simplest way to do it.

As for having 1 RPC outstanding per each connected client, that's not inherently a big deal at the server side. If the server is using a sync API, that will indeed cause a new thread per connected client, but those threads will be idle whenever the notification isn't active and so that can scale to a few thousand on a typical server system without problems. If you're using more than a few thousand simultaneous clients, you would want to use the async API and then you do all the processing in a single thread.

HTH!

@vjpai

--
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 grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
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/bd6410f9-3166-4877-90f2-992187c72f43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Vijay Pai]

Quick self-followup: "you do all the processing in a single thread" -> "you do all the processing in one or more threads as you choose." There's, of course, no restriction on your thread count with the async API. I should also clarify that this applies to the first paragraph about the client-side as well; you can use not only the same completion queue but also the same thread (or different ones, your choice).

[Julien]

Hi Vijay,

Thanks a lot for the comments.
So I will implement option 1, probably in a separate thread with the sync API.

Julien


Le vendredi 2 juin 2017 18:14:34 UTC+2, Julien a écrit :