CODEWITHSUNDEEP
c++grpc
Ken
Ken

Reputation: 457

gRPC callback vs streaming in C++

I'm writing an application where a client will connect to a server and subscribe to data updates. The client tells the server what data items it is interested in, and then subscribes using a method with a streaming response. This works well.

However, there are also non-data related notifications that the client should know about. I'm not sure about the best way to handle those. I've thought of:

  1. Adding another method to the existing service. This would be just like the data subscription but be used for event subscription. The client could then subscribe to both types of updates. Not sure what the best practice is for the number of methods in a service, or the mixing of responsibilities in a service.

  2. Exposing a second service from the server with a streaming method for event notifications. This would make the client use multiple connections to get its data - and use another TCP port. The event notifications would be rare (maybe just a few during the lifetime of the connection) so not sure if that is important to consider. Again - not sure about best practices for the number of services exposed from a server.

  3. This one seems unorthodox, but another method might be to pass connection info (IP address and port) from the client to the server during the client's connection sequence. The server could then use that to connect to the client as a way to send event notifications. So the client and server would each have to implement both client and server roles.

Any advice on ways to manage this? Seems like this a problem that would already have been solved - but it also appears that the C++ implementation of gRPC lags a bit behind some of the other languages which offer some more options.

Oh - and I'm doing this on Windows.

Thanks

Upvotes: 0

Views: 2985

Answers (1)

Ken
Ken

Reputation: 457

I've come up with another alternative that seems to fit the ProtoBuf style better than the others. I've created ProtoBuf message types for each of the data/event/etc notifications that the server should send, and enclosed each of them inside a common 'notification' message that uses the 'oneof' type. This provides a way to have a single streaming method response that can accommodate any type of notification. It looks like this:

message NotificationData
{
    oneof oneof_notification_type
    {
        DataUpdate item_data_update = 1;
        EventUpdate event_data_update = 2;
        WriteResponse write_response_update = 3;
    }
}

service Items
{
    ...
    rpc Subscribe (SubscribeRequest) returns (stream NotificationData) {}
    ...
}

Any comments or concerns about this usage?

Thanks

Upvotes: 1

Related Questions