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

О, тут раньше советовали sunRPC

Кроссплатформенная библиотека RPC

и есть порт на go:

https://github.com/prashanthpai/sunrpc

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

ЩИТО?

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

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

Используется и что? При чем тут «заточенное под оптимизацию веба»?

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

О нет!

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

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

У меня локалхост.

Какой-то набор разрозненных фактов и хотелок.

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

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

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

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

Не стреляйте в архитектора, он строит как умеет.

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

А что в json сложного?

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

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

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

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

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

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

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

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

https://github.com/hprose

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

Это нормальный формат, очень легко парсить/генерировать, оверхеда особо нет.

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

Если c-биндинги к готовым вещам использовать нельзя, то придумай свой протокол на базе TLV формата.

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

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

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

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

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

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

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

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

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

Вызов только локальный

Я бы посмотрел в сторону трифта, синхронный интерфейс с кастомным транспортом.

Ты хоть в чем-то разбираешься, мань? Хоть в чем-нибудь, в выращивании огурцов хотя бы?

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

на C

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

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

используй подмножество HTTP 1.1

минимально необходимый сабсет.

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

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

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

программист успешно мыслит английскими терминами, на кой хрен ему что-то сопоставлять?

На тот, что «подмножество HTTP 1.1» в данном примере перевести в «subset of HTTP 1.1» программист, очевидно, не смог.

В более сложных задачах таких примеров валом.

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

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

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

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

???

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

Если камень в мой огород, то читать надо внимательно.

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

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

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

Что за сепульки?

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

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

А это для решения задачи неважно.

https://en.wikipedia.org/wiki/Sepulka

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

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

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

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

О, спасибо, похоже на то, что надо.

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

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

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

Именно потому и не смог, что мыслит в английских терминах, а маня лезет с русским «подмножеством».

Эскейпинг ничего не съест, он ровно так же обрабатывается со скоростью памяти.

Base64 / urlencoded шлак при передаче бинарных данных

И что?

И дроченный JSON Number, с точность 2^52 максимум.

Откуда ты это берёшь? В JSON нет ограничений на точность чисел.

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

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

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

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

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

Я не смог подружить его со сборщиком мусора.

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

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

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

json я сильно разлюбил после https://habr.com/ru/company/mailru/blog/314014/

А в чём проблема? С тем же питоном прекрасно работает.

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

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

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

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

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 для любого языка с управлением памятью становится огромным.