Comments

Одна из самых неудобных частей серверного C++ API это uni-/bidirect стриминговые методы. Нет достаточно хорошего примера, как например обмениваться сообщениями между двумя и более клиентами. Я попытался реализовать нечто подобное в примерах для qtprotobuf, но по прежнему не до конца понятно как правильно осуществлять жонглирование контекстами и очередями сообщений. Думал будет немного освещено в статье, но к сожалению не увидел. В целом куда удобнее пользоваться Go lang серверным API.


UPD: Речь выше о WithAsyncMethod* серверах

Какой минимальный/средний оверхед у gRPC пакетов по сравнению с сырым protobuf payload (т.е. без HTTP/2 обвязки)?

Ответ очевиден, что это HTTP2 заголовок, который вы сами формируете + размер передаваемых данных(5 байт)
Но если вспомнить про то, что HTTP2 поддерживает gzip сжатие данных, думаю HTTP2 становится чуть привлекательнее чем raw protobuf payload.

Ответ очевиден

Конечно очевиден, поэтому и вопрос не в том, что составляет оверхед, а какой размер у получающегося заголовка.

Это уже сжатый HPACK и с данными gRPC (он ведь свои заголовки туда пишет — названия методов и пр.)?


Довольно много получается, пейлоады сильно меньше зачастую.

Название метода это часть URL запроса, но да это тоже входит в HTTP2 заголовок. И да это HPACK для моего сервиса с аутентификацией запросов(включает собственные заголовки авторизации).

Как альтернатива gRPC указан WSDL. Подразумевается какое-то отличное от SOAP использование WSDL? Или вместо протокола SOAP случайно указан язык описания, лежащий в его основе?

Проблема текущих реализаций gRPC, как мне кажется, в том что они гвоздями прибиты к Protobuf и не поддерживают других сериализаторов.


В ситуациях где есть очень большая нагрузка использовать Protobuf становится достаточно накладно. По крайней мере в Go десериализация вызывает много мусора даже на gogo-protobuf. И если поток данных большой то процессор больше времени проводит собирая мусор чем делая полезное дело. На плюсах в режиме reuse вроде бы ситуация получше, но все равно не очень.


В Cap'n'Proto дела получше, но, по крайней мере в Go-либе, аллокации все равно есть на каждое сообщение разобранное.


В итоге мы уехали на flatbuffers вместо protobuf в своем проекте и не имеем проблем с накладными расходами. Но у нас не gRPC, да и использовать flatbuf довольно неудобно местами.

А разве GraphQL не подходит как аналог? Тоже описываем типы входных параметров и возвращаемых значений, сигнатуры вызываемых процедур и пр? Да, стримминга вроде как там нет, но есть подписки. В целом, вроде звучит похоже
Кстати есть отличный Open Sorce проект на основе gRPC. Позволяет строить свои акторы на С#, GO, Python, Kotlin. Proto Actor
Only those users with full accounts are able to leave comments. Log in, please.