LINUX.ORG.RU

ищется протокол удалённого вызова процедур

 


0

2

Клиент - C++, Сервер - программа на языке со сборкой мусора. Вызов только локальный. Нужно уметь описывать интерфейсы, хранить ссылки на удалённые объекты, генерировать обёртки и всё вот это вот.

Основное требование - это простота реализации и независимость от библиотек, т.к. придётся портировать на новый язык, в котором ничего нет (даже json).

Поэтому ищется какая-то компактная многоязычная библиотечка.

Второе требование - пермиссивная лицензия.

В текущем самодельном прототипе используются сокеты. Вроде этого пока должно быть достаточно.

Посмотрел:

  • SOAP - на базе XML = тормоза.
  • Protobuf - формат можно рассмотреть, хотя у меня нет цели слишком сжимать данные, а они там похоже на это запарились.
  • grpc - оказывается, там какое-то http/2, заточенное под оптимизацию веба. Мне это абсолютно не нужно
  • erpc - только Си
  • CORBA - вроде громоздкая?

Фавориты:

★★★★★

Ответ на: комментарий от Reset

gRPC (Remote Procedure Calls) — это система удалённого вызова процедур (RPC) с открытым исходным кодом, первоначально разработанная в Google в 2015 году. В качестве транспорта используется HTTP/2, в качестве языка описания интерфейса — буферы протоколов. gRPC предоставляет такие функции как аутентификация, двунаправленная потоковая передача и управление потоком, блокирующие или неблокирующие привязки, а также отмена и тайм-ауты. Генерирует кроссплатформенные привязки клиента и сервера для многих языков.

Я что-то не то написал? Или русская википедия?

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)

там какое-то http/2, заточенное под оптимизацию веба. Мне это абсолютно не нужно

О нет!

А в C++ точки с запятой порождают грустные смайлики, оно тебе надо?

t184256 ★★★★★ ()

RPC в принципе не заточен на обработку ошибок транспорта. Считает, что транспорт работает всегда. Соответственно, у тебя два варианта: (1) У тебя localhost или локалка, в рамках которой ты тоже можешь позволить себе считать, что транспорт работает всегда. (2) А если ты начнёшь костылить эту обработку ошибок самостоятельно, то в случае если ты юный гений, ты придёшь к собственной реализации REST (в т.ч. с идемпотентностью и т.д.); но гораздо вероятнее получишь нечто гораздо более громоздкое и корявое.

dimgel ★★★★ ()
Ответ на: комментарий от Reset

Мне нужно будет портировать код сервера на малоизвестный язык. Чем меньше код, тем меньше работы.

Нашёл вот это:

https://github.com/topics/remote-procedure-calls

Склоняюсь к json-rpc, только нужно будет вместо json использовать более простой формат.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)

Любой популярный формат сложный. Лучше сразу пили свой. Если у тебя хотелок немного, это будет оптимально. Для транспорта используй подмножество HTTP 1.1, его легко можно хоть на C в несколько сотен строк реализовать. Для данных - JSON. Это нормальный формат, очень легко парсить/генерировать, оверхеда особо нет. Если объекты с данными будут большими, всегда можно прикрутить прозрачное gzip сжатие.

Как вариант - json-rpc возьми за основу и какое-нибудь его подмножество используй, которого тебе хватит.

Legioner ★★★★★ ()

сокет это транспорт.

protobuf, msgpak, flatbuffers, тот же JSON это упаковка и фрейминг.

rpc это описание механизма взаимодействия.

не зная задачу трудно что-то советовать, но если все крутится в пределах одного сервака, обычно можно обойтись без всего этого зоопарка.

и да, если нет особых требований по пропускной способности, JSON наше все, как тут уже советовали.

anonymous ()
Ответ на: комментарий от den73

Мне нужно будет портировать код сервера на малоизвестный язык. Чем меньше код, тем меньше работы.

https://github.com/hprose

Очень лаконичный код и достаточно быстрая реализация. Поддержка ссылок в отличие от JSON.

monk ★★★★★ ()
Ответ на: комментарий от Reset

Это не значит, что его парсер сложно написать. Да и в плане загрузки ЦПУ - по сравнению с чем? Если брать текстовые форматы, то, полагаю, JSON будет весьма быстрым. Того же XML.

KivApple ★★★★★ ()
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от Reset

json сложно и генерировать и парсить, один из самых cpu нагружающих форматов.

С чего ты это взял, не пойму? Лексер там примитивнейший. Синтакс примитивнейший. Там нечему нагружать CPU, он будет работать со скоростью памяти, что при парсинге, что при генерации. Причём нет никаких проблем со стримингом.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

С чего ты это взял, не пойму?

С того, что я на этом собаку съел.

Лексер там примитивнейший. Синтакс примитивнейший.

И какая связь со скоростью?

Там нечему нагружать CPU, он будет работать со скоростью памяти, что при парсинге, что при генерации.

Не будет. У тебя как минимум эскейпинг съест все.

Reset ★★★★★ ()
Ответ на: комментарий от Legioner

используй подмножество HTTP 1.1, его легко можно хоть на C в несколько сотен строк реализовать

на C

несколько сотен строк

Только если ты подразумеваешь минимально необходимый сабсет.

WitcherGeralt ★★ ()
Ответ на: комментарий от anonymous

По логике Аристотеля «подмножество» != «сабсет»

И потом утверждают, что программировать по-русски не надо, программист прекрасно в уме сопоставляет английские термины с русскими.

monk ★★★★★ ()
Ответ на: комментарий от monk

прекрасно в уме сопоставляет … термины

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

anonymous ()
Ответ на: комментарий от anonymous

Не понимаю к чему сарказм. Я уточнил, что «минимально необходимый». picohttpparser — 700 c небольшим строк вместе с хедером, и это просто парсер без логики, и каких-либо хелперов, чтобы юзабельно было. А если это хоть что-то вменяемое уже будет, то косаря полтора точно.

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 1)
Ответ на: комментарий от anonymous

Пусть лучше сопоставляет свои реальные ощущения с терминами.

???

В задаче «Написать программу учёта сепулек. Сепульки могут приходоваться накладными с указанием вида сепулек и их количества, могут списываться требованиями с аналогичным указнием. Нужна возможность получения остатка в разрезе видов сепулек на произвольную дату» какие реальные ощущения соответствуют терминам «сепульки», «вид сепулек», «накладная», «требование», «остаток»?

monk ★★★★★ ()
Последнее исправление: monk (всего исправлений: 1)

Раздели задачу на две

  • серриализация и
  • транспорт.

Ибо они никак не связаны. И что значит ЯП в котором ничего нет? Там TCP есть?

anonymous ()
Ответ на: комментарий от WitcherGeralt

Я уточнил, что «минимально необходимый».

Подмножество может быть меньше минимально необходимого. Видел формат хранения текста с картинками в виде подмножества HTML. Подмножество было из элемента IMG. Парсер этого формата нельзя назвать парсером HTML (даже минимальным), но он является парсером подмножества HTML.

monk ★★★★★ ()
Ответ на: комментарий от Legioner

Для транспорта используй подмножество HTTP 1.1, его легко можно хоть на C в несколько сотен строк реализовать. Для данных - JSON. Это нормальный формат, очень легко парсить/генерировать, оверхеда особо нет.

Base64 / urlencoded шлак при передаче бинарных данных. И дроченный JSON Number, с точность 2^52 максимум.

anonymous ()
Ответ на: комментарий от monk

В задаче «Написать программу учёта сепулек.

Более-менее реальна только задача. А вот остальное - это отрыв от реальности. Иногда можно раскрутить заказчика на реальные бумажки «Билеты Банка …» на этот отрыв от реальности

anonymous ()
Ответ на: комментарий от monk

Подмножество было из элемента IMG

Ну, збс теперь. Пересечение настолько несущетвенное, что всерьёз назвать это сабсетом HTML нельзя, оно может быть вообще случайным.

А мы в контексте протокола говорим. Он рабочий должен быть. Урежешь до минимально необходимого для твоего приложения, может получиться так, что готовая библиотека такое не переварит.

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 1)

Лично я бы заюзал Cap’n Proto, это примерно как gRPC, только по-человечески.

JSON-RPC тоже норм, простой-человекопонятный, но из плюсов им не очень удобно пользоваться, и с описанием схем и кодогенерацией там всё так себе.

Ну и если сейчас используются тупо сокеты, то вот ещё в копилку: nng, бывший nanomsg, который идейный потомок ZeroMQ. Там как раз автоматическая обработка ошибок соединения, автоматический реконнект и т. д.

anonymous ()
Ответ на: комментарий от anonymous

Так пусть мыслящие в английских терминах работают с англоязычными заказчиками или хотя бы постановку задач требуют в английских терминах. Будет гораздо меньше ошибок.

monk ★★★★★ ()
Ответ на: комментарий от monk

мыслящие в английских терминах

постановку задач требуют в английских терминах

Тогда тоже упрется в «логику Аристотеля» - терминов меньше, чем реальных объектов - будут конфликты. Чур, арабские цифры использовать нельзя!

anonymous ()
Ответ на: комментарий от anonymous

Тогда тоже упрется в «логику Аристотеля» - терминов меньше, чем реальных объектов - будут конфликты.

В английском языке достаточно словосочетаний для идентификации любого объекта с необходимой степенью точности. Какие конфликты?

monk ★★★★★ ()
Ответ на: комментарий от anonymous

С тем же питоном прекрасно работает.

Похоже, что со сборкой мусора никак не работает:

Every call to init allocates new memory inside your Cap’n Proto message, and if you call it more than once, the previous memory is left as dead space in the message.

И в примере работы с ним невозможно вложить готовый объект в сообщение, только получить объект из шаблона сообщения и заполнить его поля. То есть encoding round-trip для любого языка с управлением памятью становится огромным.

monk ★★★★★ ()