Как реализовать долго выполняющиеся потоковые обновления данных gRP C asyn c на сервере C ++ - PullRequest
0 голосов
/ 19 марта 2020

Я создаю асин c gRP C сервер в C ++. Один из методов потоковой передачи данных с сервера клиентам - используется для отправки обновлений данных клиентам. Частота обновления данных не предсказуема. Они могут быть почти непрерывными или такими же редкими, как раз в час. Модель, используемая в примере gRP C с классом "CallData" и состояниями CREATE / PROCESS / FINI SH, похоже, для этого не очень хорошо работает. Я видел пример , который показывает, как создать 'опрос' l oop, который некоторое время спит, а затем просыпается, чтобы проверить новые данные, но это не кажется очень эффективным.

Есть ли другой способ сделать это? Если я использую метод «CallData», может ли он блокироваться в состоянии «PROCESS» до тех пор, пока не появятся данные (что, вероятно, не будет моим первым выбором)? Или лучше, я могу структурировать свой код так, чтобы я мог уведомить обработчик gRP C, когда данные будут доступны?

Любые идеи или примеры будут оценены.

1 Ответ

0 голосов
/ 25 марта 2020

В примере потоковой передачи на стороне сервера вам, вероятно, нужно больше состояний, потому что вам нужно отслеживать, выполняется ли в данный момент запись. Я бы добавил два состояния: одно с именем WRITE_PENDING, которое используется, когда выполняется запись, и другое с именем WRITABLE, которое используется, когда новое сообщение может быть отправлено немедленно. Когда создается новое сообщение, если вы находитесь в состоянии WRITABLE, вы можете отправить его немедленно и go в состояние WRITE_PENDING, но если вы находитесь в состоянии WRITE_PENDING, то вновь созданное сообщение должно go в очередь для отправки. после окончания текущей записи. Когда запись заканчивается, если очередь не пустая, вы можете получить следующее сообщение из очереди и немедленно начать запись для него; в противном случае вы можете просто go перейти в состояние WRITABLE и дождаться выдачи другого сообщения.

Здесь не нужно блокировать, и вы, вероятно, не захотите делать это в любом случае, потому что это будет t ie поток, который в противном случае должен опрашивать очередь завершения. Если все ваши потоки будут заблокированы таким образом, вы будете слепы к новым событиям (таким как поступающие новые вызовы).

Альтернативой здесь может быть использование C ++ syn c API, который гораздо проще в использовании. В этом случае вы можете просто написать прямой код блокировки. Но цена заключается в том, что он создает один поток на сервере для каждого выполняемого вызова, поэтому это может оказаться невозможным, в зависимости от количества обрабатываемого трафика c.

Надеюсь, эта информация полезно!

...