Добрый день @ptr128. Я когда начинал смотреть на эту тему нашел тут на хабр много статей про JSON-RPC и сравнения с gRPC. Какой именно протокол использовать с своем проекте и какие библиотеки каждый решает сам. При чем скорость не всегда является главным критерием выбора. Конечно бинарные протоколы имеют большую компактность. Но на небольших сообщениях, которые умещаются в один сетевой пакет скорость примерно одинаковая. Так как отправка/прием пакета это 1 DMA инструкция на сетевой карте и проброс этого пакета в стек ОС. А вот то что JSON-RPC текстовый это и есть его основной плюс. Это как поддержание архитектурного API где-нибудь в git, так и средства отладки (tcpdump, eBPF, команды из telnet). В общем все зависит от области применения.
>А в чем прикол конфигурацию для клиента и сервера передавать строкой с JSON?
Хотелось иметь FFI-friendly конструктор. Строка оканчивающаяся нулем она на всех языках строчка. А json там уже встроенный.
> Зачем-то client_register возвращает вместо структуры - JSON с результатом операции и потом там надо выдергивать ключи по строкам, что тоже очень странно.
Мне показался такой подход интересным. В начале очень помогало мапить с тем что из шины прилетело, когда там гонки были внутри. Сейчас стабильно работает, можно будет и переделать. Но пока не уверен что будет лучше.
>Было бы ещё неплохо добавить функционал, чтобы параметры методов мапились на переменные, чтобы их самому не кастовать и не брать по индексу.
Согласен, было бы удобнее.
>Есть ли планы выложить в Conan, VCPKG?
Вот сейчас появились. У меня основная специализация это kenel, загрузчики, data plane и системный софт. Эти слова я впервые слышу. В репозитории конечно имеет смысл добавить как и debian. Спасибо. Вот только бы время на это найти...
Спасибо @cyanidle на FastPimpl действительно стоит посмотреть. Бенчмарки у меня есть разные, но данную статью уж очень не хотелось перегружать информацией. И это уже тема для отдельного исследования. Релевантные модели прям сложно подобрать потому что muRPC это скорее шина чем просто сервер. Может быть надо было это как-то дополнительно уточнить в статье.
Я посмотреть ваш rpcxx проект. Довольно интересно. Я думал как поддерживать другие транспорты и наверное тут лучшее решение это из одного клиента сделать прокси. С одной стороны он будет соединяться с muRPC шиной, а другой стороны предоставлять уже требуемый транспорт (Web Sockets, Rest, UDP и что там еще.).
ubjson/msgpack/cbor - да, согласен. Но plain text можно снифать. А это я бы сказал хороший плюс.
На сервере, тоже как и на клиенте можно регистрировать методы. Вот прям в примере тоже для теста у меня есть метод add:
Уважаемый @DrunkSkipper спасибо за комментарий, я не знал что у SPDK есть json-rpc. На сколько я вижу spdk_rpc_register_method предназначена только для вызова внутри самого сервера. Ее вызов SPDK_RPC_REGISTER делает привязку в моменте компиляции. А клиентские вызовы spdk_jsonrpc_client_* предоставляет только функции для подключения к серверу, отправки запросов и получения ответов. Нет никаких функций, позволяющих клиенту регистрировать свои методы на сервере. Отсутствует поддержка уведомлений - в json-rpc это запросы без id полей. И это в корне меняет всю картину. Необходимость отслеживать соединения, принадлежность вызовов, делать маршрутизацию запросов/ответов, асинхронное API - вот сила muRPC.
Добрый день @ptr128. Я когда начинал смотреть на эту тему нашел тут на хабр много статей про JSON-RPC и сравнения с gRPC. Какой именно протокол использовать с своем проекте и какие библиотеки каждый решает сам. При чем скорость не всегда является главным критерием выбора. Конечно бинарные протоколы имеют большую компактность. Но на небольших сообщениях, которые умещаются в один сетевой пакет скорость примерно одинаковая. Так как отправка/прием пакета это 1 DMA инструкция на сетевой карте и проброс этого пакета в стек ОС. А вот то что JSON-RPC текстовый это и есть его основной плюс. Это как поддержание архитектурного API где-нибудь в git, так и средства отладки (tcpdump, eBPF, команды из telnet). В общем все зависит от области применения.
@navrocky привет,
>А в чем прикол конфигурацию для клиента и сервера передавать строкой с JSON?
Хотелось иметь FFI-friendly конструктор. Строка оканчивающаяся нулем она на всех языках строчка. А json там уже встроенный.
> Зачем-то client_register возвращает вместо структуры - JSON с результатом операции и потом там надо выдергивать ключи по строкам, что тоже очень странно.
Мне показался такой подход интересным. В начале очень помогало мапить с тем что из шины прилетело, когда там гонки были внутри. Сейчас стабильно работает, можно будет и переделать. Но пока не уверен что будет лучше.
>Было бы ещё неплохо добавить функционал, чтобы параметры методов мапились на переменные, чтобы их самому не кастовать и не брать по индексу.
Согласен, было бы удобнее.
>Есть ли планы выложить в Conan, VCPKG?
Вот сейчас появились. У меня основная специализация это kenel, загрузчики, data plane и системный софт. Эти слова я впервые слышу. В репозитории конечно имеет смысл добавить как и debian. Спасибо. Вот только бы время на это найти...
Здравствуйте @AbuMohammed. Тамауты задаются при инициализации. Например вот https://github.com/skbuff-ru/muRPC/blob/master/tests/client_interop_test.cpp#L34 При асинхронном api вы получите в колбеке результата либо ок, либо ошибку таймаута.
Спасибо @cyanidle на FastPimpl действительно стоит посмотреть. Бенчмарки у меня есть разные, но данную статью уж очень не хотелось перегружать информацией. И это уже тема для отдельного исследования. Релевантные модели прям сложно подобрать потому что muRPC это скорее шина чем просто сервер. Может быть надо было это как-то дополнительно уточнить в статье.
Я посмотреть ваш rpcxx проект. Довольно интересно. Я думал как поддерживать другие транспорты и наверное тут лучшее решение это из одного клиента сделать прокси. С одной стороны он будет соединяться с muRPC шиной, а другой стороны предоставлять уже требуемый транспорт (Web Sockets, Rest, UDP и что там еще.).
ubjson/msgpack/cbor - да, согласен. Но plain text можно снифать. А это я бы сказал хороший плюс.
На сервере, тоже как и на клиенте можно регистрировать методы. Вот прям в примере тоже для теста у меня есть метод add:
https://github.com/skbuff-ru/muRPC/blob/master/examples/server.cpp#L105
server.register_method("add", [](const muRPC::Json& request) {Уважаемый @DrunkSkipper спасибо за комментарий, я не знал что у SPDK есть json-rpc. На сколько я вижу spdk_rpc_register_method предназначена только для вызова внутри самого сервера. Ее вызов SPDK_RPC_REGISTER делает привязку в моменте компиляции. А клиентские вызовы spdk_jsonrpc_client_* предоставляет только функции для подключения к серверу, отправки запросов и получения ответов. Нет никаких функций, позволяющих клиенту регистрировать свои методы на сервере. Отсутствует поддержка уведомлений - в json-rpc это запросы без id полей. И это в корне меняет всю картину. Необходимость отслеживать соединения, принадлежность вызовов, делать маршрутизацию запросов/ответов, асинхронное API - вот сила muRPC.