gRPC 回调与 C++ 中的流式传输答案

【问题标题】：gRPC callback vs streaming in C++gRPC 回调与 C++ 中的流式传输
【发布时间】：2020-08-08 11:59:47
【问题描述】：

我正在编写一个应用程序，客户端将连接到服务器并订阅数据更新。客户端告诉服务器它感兴趣的数据项，然后使用带有流式响应的方法进行订阅。这很好用。

但是，也有客户应该知道的与数据无关的通知。我不确定处理这些问题的最佳方法。我想到了：

向现有服务添加另一种方法。这就像数据订阅一样，但用于事件订阅。然后客户端可以订阅这两种类型的更新。不确定服务中的方法数量或服务中的职责混合的最佳做法是什么。
使用事件通知的流式方法从服务器公开第二个服务。这将使客户端使用多个连接来获取其数据 - 并使用另一个 TCP 端口。事件通知很少见（在连接的生命周期中可能只有少数），因此不确定这是否重要。同样 - 不确定从服务器公开的服务数量的最佳实践。
这似乎不合常规，但另一种方法可能是在客户端的连接序列期间将连接信息（IP 地址和端口）从客户端传递到服务器。然后，服务器可以使用它连接到客户端作为发送事件通知的一种方式。所以客户端和服务器都必须同时实现客户端和服务器角色。

关于如何管理此问题的任何建议？似乎这是一个已经解决的问题 - 但 gRPC 的 C++ 实现似乎落后于其他一些提供更多选项的语言。

哦 - 我正在 Windows 上执行此操作。

谢谢

【问题讨论】：

标签： c++ grpc

【解决方案1】：

我想出了另一个替代方案，它似乎比其他方案更适合 ProtoBuf 风格。我为服务器应发送的每个数据/事件/等通知创建了 ProtoBuf 消息类型，并将它们中的每一个都包含在使用“oneof”类型的通用“通知”消息中。这提供了一种方法来获得可以容纳任何类型通知的单个流方法响应。它看起来像这样：

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) {}
    ...
}

对这种用法有任何问题或顾虑吗？

谢谢

【讨论】：