Что происходит, когда сервер grp c повторно вызывает Send, но клиент grp c никогда не вызывает Recv? - PullRequest
0 голосов
/ 30 апреля 2020

У меня есть клиентское приложение grp c, которое может время от времени блокироваться, что приводит к ситуации, когда он не может некоторое время вызывать функцию grp c Recv. Какое поведение наблюдается на сервере GRP c в этой ситуации? Блокирует ли сервер отправки вызовов grp c? Он блокируется до тех пор, пока Recv не будет вызван на клиенте?

Ответы [ 2 ]

0 голосов
/ 06 мая 2020

И, в конце концов, если читатель не читает так быстро, как отправляет отправка, управление потоком сработает, и отправитель будет заблокирован (пока читатель не прочитает больше).

0 голосов
/ 01 мая 2020

Клиент и сервер могут читать и писать сообщения в любом порядке, и это полностью определяется приложением c. Так что, отвечая на ваш вопрос, клиент на какое-то время блокируется, возможно, после истечения времени ожидания сообщение падает на пол.

Обработка потоков на стороне клиента и на сервере определяется приложением c. Поскольку оба потока независимы, клиент и сервер могут читать и записывать сообщения в любом порядке. Например, сервер может подождать, пока он не получит все клиентские сообщения, прежде чем писать свои сообщения, или сервер и клиент могут сыграть в «пинг-понг» - сервер получает запрос, затем отправляет ответ, затем клиент отправляет другой запрос на основе ответа и т. д.

Посмотрите, как это объясняется в официальной документации gRP C. Также примите во внимание, что есть специфичные для языка данные c, поэтому убедитесь, что вы проверили справочную документацию на ваш язык.

https://grpc.io/docs/guides/concepts/#rpc -life-cycle https://grpc.io/docs/guides/concepts/#synchronous -vs асинхронный

...