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

Ну по идее-то ссылки на удалённые объекты - это всего лишь таблица этих ссылок и инвалидация при отпадении сервера. Вроде не кажется сложным, причём я такое уже делал, правда для FFI, а не для RPC. Не было сложным. Но может быть я чего-то недопонял.

ссылки - это … таблица этих ссылок

Рекурсивное определение детектед

я такое уже делал

Для зоопарка языков, с и без автоматического сборщика мусора? И или конкретный костыль для конкретных языков?

У меня простой RPC, без проброса исключений с сервера и описания сигнатур функции, в последний раз занял где то пару часов (клиент на питоне, сервер на плюсах). С отладкой, с нуля - это при том что я не считаю себя программистом. Правда я такую штуку не в первый раз делал и точно знал что и как, сам протокол у меня давно был готов на основе питоньего модуля struct.

Мне кажется тут дольше с готовой библиотекой разбираться будешь.

Вроде не кажется сложным

нуну. распределённый gc это не сложно, да.

Зависит от функционала. То что den хочет и правда несложно.

Конкретный, но не надо путать мои скромные возможности и всемирно известные open-source проекты.

Речь о gc не идёт.

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

Вы так говорите как будто это что то плохое.

Намек понял int err = close(f); if (err != 0) goto panic

Я не очень знаком с теорией. Но если под передачей ссылок на удаленные обьекты подразумевается, что в RPC метода можно вернуть какой-то об’ект клиентского ЯП, и клиент на этом об’екте сможет вызвать тот же метод и таким же простым способом, как первый вызов, то такого в Thrift я не видел. Максимум, что можно сделать - возвращать URL другого сервера (с таким же интерфейсом или с другим), вручную переподключать клиента к этому адресу или создавать/переиспользовать нового клиента. Т.е. короче, Thrift - это такая клиент-серверная сеть, с генератором исходника клиента/сервера плюс транспорты плюс сериалайзеры/десериалайзеры.

Вроде как-то так.

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

Я вообще такое только в Erlang видел, где на узел можно перекинуть открытый файл или сформированное окно ГИП.

Вот для Си++: https://www.adamtornhill.com/code/tinchpp.htm

Правда здесь тоже никакого IDL нет.

Ну ведь в COM в офтопике это есть, а в DCOM это можно растаскивать как минимум по процессам. Видимо, в CORBA тоже. Мне не казалось это каким-то шиком. Понятно, что перекинуть вообще говоря нельзя ввиду того, что удалённый узел может упасть. Но за вычетом этого падения - можно. Т.е. логика будет другая, но способ вызова - такой же.

Сами по себе кроссязыковые обвязки делаются в SWIG, для тяжёлого языка, такого, как C++. Т.е. там генерируются, скажем, обвязки для заранее выбранных воплощений шаблонов, и код на клиентской стороне, позволяющий эти же функции вызывать, и экземпляры пробрасываются, и эксепшены, и плюсовый объект становится, скажем, питоновским объектом с одноимёнными методами.

Просто в качестве транспорта используется FFI, а не, скажем, сокеты.

Был бы у меня SWIG на стороне сервера, а не клиента - я бы уже подумал прикрутить сокеты к свигу вместо FFI.

Т.е. там генерируются, скажем, обвязки для заранее выбранных воплощений шаблонов, и код на клиентской стороне, позволяющий эти же функции вызывать, и экземпляры пробрасываются, и эксепшены, и плюсовый объект становится, скажем, питоновским объектом с одноимёнными методами.

Это плохо сочетается с «простота реализации и независимость от библиотек». COM/DCOM видел сколько занимает?

Был бы у меня SWIG на стороне сервера, а не клиента - я бы уже подумал прикрутить сокеты к свигу вместо FFI.

Так может проще SWIG расширить http://www.swig.org/Doc4.0/Extending.html#Extending_nn31 ?

Это клиентская сторона, а мне нужно серверную на своём языке, клиентскую на C++.

В JSON нет ограничений на точность чисел.

128 байт максимальная длина числа. Но когда передаёшь это дело в JS там оно превращается в JS Number. Он же IEEE754. Аналогично если делаешь это с обратной стороны. Или для исследования и отладки используешь JS-утилиты.

Отталкиваться от формата само по себе не очень. Отталкиваться нужно от того, что передаёшь. Может 0-terminated строк достаточно.