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).
On Tue, Jun 6, 2017 at 2:21 AM Vijay Pai <[email protected]> wrote: > 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 > > On Tue, Jun 6, 2017 at 2:07 AM 'Julien' via grpc.io < > [email protected]> wrote: > >> Any idea? >> Any comment on this? >> >> Thanks. >> >> Julien >> >> >> >> Le vendredi 2 juin 2017 18:14:34 UTC+2, Julien a écrit : >>> >>> 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 >>> >>> -- >> 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/bd6410f9-3166-4877-90f2-992187c72f43%40googlegroups.com >> <https://groups.google.com/d/msgid/grpc-io/bd6410f9-3166-4877-90f2-992187c72f43%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/CADEy0h1U3yxr5UUe%2B374ae0de5-UgnH1CkQk-4g9AXPzAGAYQg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
