обратный вызов gRP C против потоковой передачи в C ++ - PullRequest
Новая
       6

обратный вызов gRP C против потоковой передачи в C ++

0 голосов
/ 24 апреля 2020

Я пишу приложение, в котором клиент будет подключаться к серверу и подписываться на обновления данных. Клиент сообщает серверу, какие элементы данных ему интересны, а затем подписывается, используя метод с потоковым ответом. Это хорошо работает.

Однако существуют также уведомления, не связанные с данными, о которых клиент должен знать. Я не уверен в том, как лучше всего справиться с этим. Я думал о:

  1. Добавление другого метода в существующую службу. Это будет похоже на подписку на данные, но будет использоваться для подписки на события. Затем клиент может подписаться на оба типа обновлений. Не уверен, что лучше всего использовать количество методов в службе или смешивать обязанности в службе.

  2. Предоставление второй службы с сервера с потоковым методом для события уведомления. Это заставит клиента использовать несколько соединений для получения своих данных и использовать другой порт TCP. Уведомления о событиях будут редкими (возможно, всего несколько в течение времени жизни соединения), поэтому не уверен, что это важно учитывать. Опять же - не уверен в лучших рекомендациях по количеству сервисов, предоставляемых с сервера.

  3. Этот способ кажется неортодоксальным, но другим способом может быть передача информации о соединении (IP-адрес и порт) из клиент к серверу во время последовательности подключения клиента. Затем сервер может использовать это для подключения к клиенту в качестве способа отправки уведомлений о событиях. Таким образом, каждый клиент и сервер должны будут выполнять роли клиента и сервера.

Какой-нибудь совет по поводу способов управления этим? Кажется, что это проблема, которая уже была бы решена - но также кажется, что реализация gRP C на C ++ немного отстает от некоторых других языков, которые предлагают еще больше опций.

О - и я Я делаю это на Windows.

Спасибо

1 Ответ

1 голос
/ 25 апреля 2020

Я придумала другую альтернативу, которая, кажется, подходит стилю ProtoBuf лучше, чем другие. Я создал типы сообщений ProtoBuf для каждого из уведомлений data / event / et c, которые должен отправлять сервер, и вложил каждое из них в общее сообщение-уведомление, использующее тип «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) {}
    ...
}

Есть ли какие-либо комментарии или замечания по поводу этого использования?

Спасибо

...