Использование Sun RPC

повсеместно внутри *BSD?

// wbr

Эээ... не понял. Имеются в виду традиционные NFS-сервисы или что-то более другое?

>Кто-нибудь использовал SunRPC в современных проектах?

Не знаю насчет Sun и современных проектов, а в GNU/Hurd любое высокоуровневое взаимодействие осуществляется через RPC. Каждый сервер определяет свой интерфейс в defs файле, который собирается mig (mach interface generator) в заглушки для клиента и сервера. Непосредственно вызов осуществляется через механизм сообщений (mach message), который доступен через интерфейс системных вызовов. Например, сервер файловой системы представляет собой обычную программу, экспортирующую libfs и зарегистрировавшую в ней свои файловые/директорные операции, а также передавшую управление туда в цикл обработки сообщений (аналогично GUI программам), которые разгребаются частично libfs, а частично непосредственно файловой системой через зарегистрированные ей callbacks.

Поскольку MacOS тоже строится на mach/oskit, то там, вероятно, точно такая же ситуация.

тут имелось в виду именно SUN rpc, а не GNU/HURD rpc. С тем же успехов могли про CORBA написать.

>С тем же успехов могли про CORBA написать.

Вы действительно не видите разницу между высокоуровневыми технологиями вроде CORBA/RMI/etc и низкоуровневыми вроде SunRPC/MSRPC/HurdRPC?

>тут имелось в виду именно SUN rpc, а не GNU/HURD rpc. тут имелось в виду именно SUN rpc, а не GNU/HURD rpc.

Может оставим tailgunner право решать, что он имел в виду? Он вроде как вам оное не делегировал.

Что такое CORBA - я знаю, она сильно избыточна для моей задачи. Что такое Mach (и L4 :) ) RPC, я тоже знаю. Вопрос имнно о Sun RPC, и именно о том, применяют ли его в новых проектах.

> Что такое CORBA - я знаю, она сильно избыточна для моей задачи. Что такое Mach (и L4 :) ) RPC, я тоже знаю. Вопрос имнно о Sun RPC, и именно о том, применяют ли его в новых проектах.

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

// wbr

> можно огласить задачу целиком?

В деталях - нет. В общих чертах - необходимо средство RPC для взаимодействия между программами, выполняющимися на процессорах разных архитектур. Средство должно быть: 1) простым - небольшой объем кода, легкая понимаемость и модифицируемость, открытый (или хотя бы доступный) код; 2) должно легко интегрироваться в существующие Си/Си++ программы: нужно экспортировать из существующих программ наружу довольно много уже существующих Си-структур; 3) Биндинги к Python - большой плюс, к Java - плюс. ИМХО, CORBA не очень подходит по 2 с ее любовью поселять все генерируемые из IDL структуры в отдельные namespace, так что внутри приходится делать маршаллинг из внутренних "родных" Си-структур в CORBA-объекты.

> понятия "проекты, новые, применимость" чрезвычайно расплывчаты.

Если сказать, что я не в теме по практике применения Sun RPC, и хотел бы знать, нет ли в нем общеизвестных подводных камней и граблей - будет четче? :D

> В деталях - нет. В общих чертах - необходимо средство RPC для взаимодействия между программами, выполняющимися на процессорах разных архитектур. Средство должно быть: 1) простым - небольшой объем кода, легкая понимаемость и модифицируемость, открытый (или хотя бы доступный) код;

оч относительное требование. к чему оно применимо - к конечному генерируемому коду? к коду самого rpcgen? генератору кода из IDL? к их неизбежной обвязке? etc... пока что рассматривать не будем.

> 2) должно легко интегрироваться в существующие Си/Си++ программы: нужно экспортировать из существующих программ наружу довольно много уже существующих Си-структур;

AFAIR Sun RPC в принципе без особых проблем, хотя стоит уточнить. я с ним не общался уже N лет. CORBA - вперёд и с песнею. в обоих случаях естественное одно но: придётся переводить существующие структуры руками в ту или иную форму IDL. практика перевода сильно зависит от объёма, сложности и пр.

> 3) Биндинги к Python - большой плюс, к Java - плюс.

у того-же ACE есть конечно же связка с C++ и, возможно, Java. хотя в последнем совсем не уверен. разве что за год что-то серьёзно поменялось.

> ИМХО, CORBA не очень подходит по 2 с ее любовью поселять все генерируемые из IDL структуры в отдельные namespace,

не используйте module и не будет отдельного пространства имён :) хотя это конечно неправильно и может лучше всё-таки что-то поменять в подходе/хотелке... пространства имён все-таки рулят.

> так что внутри приходится делать маршаллинг из внутренних "родных" Си-структур в CORBA-объекты.

с C жопа. вывод скорее - RPC но не CORBA. вторая, хотя и имеет спецификацию биндингов к C, но лично я ни разу не видел ни реализации такого ORBа ни применения.

ps: хотя я конечно отнюдь не специалист ни по RPC ни по CORBA, скорее так, "сталкивался"...

// wbr

> у того-же ACE есть конечно же связка с C++ и, возможно, Java. хотя в последнем совсем не уверен. разве что за год что-то серьёзно поменялось.

ps: конечно же не ACE а TAO, как реализация CORBA поверх ACE.

// wbr

А вы на DBus смотрели? По сети он умеет, он лёгок в использовании, биндинги есть к разным языкам, он открыт и активно используется и развивается. Но счёт работы с разными архитектурами не уверен.

> А вы на DBus смотрели? По сети он умеет, он лёгок в использовании, биндинги есть к разным языкам, он открыт и активно используется и развивается. Но счёт работы с разными архитектурами не уверен.

нет, dbus я не смотрел. для него есть стабильная кросс-платформенная реализация под *nix/windows?

// wbr

Вполне стабильно, на нём работает hal,bluez-utils. Под винду порт тоже есть. А так проще сходить на сайт и самому всё узнать...

> А вы на DBus смотрели?

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

> биндинги есть к разным языкам

А я вроде нашел биндинги RPC к Python :)

> он открыт и активно используется и развивается.

Это большой плюс

Видел тест, где разница между посылкой данных через сокет и через DBus состовляла около процента. Но, естественно, оно не разрабатывалось как замена corba в плане работы в сети. К тому же там используется клиент-сервер, то есть сервер DBus принимает сообщение и отправляет их тем, кто на них подписался. В этом может быть серъёзный bottleneck.

> Видел тест, где разница между посылкой данных через сокет и через DBus состовляла около процента. Но, естественно, оно не разрабатывалось как замена corba в плане работы в сети. К тому же там используется клиент-сервер, то есть сервер DBus принимает сообщение и отправляет их тем, кто на них подписался. В этом может быть серъёзный bottleneck.

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

// wbr

> ну а ещё он жестко завязан на обмен сообщениями через тот или иной канал связи и в нем не получится сделать финт ушами, когда объекты A и B живут в параллельных потоках

Справедливости ради, этого нет и в SunRPC. Да мне это и не нужно - я же говорю, большая часть возможностей CORBA для меня просто лишние.

Если кому нужны релизация SunRPC в Python - http://www.citi.umich.edu/projects/nfsv4/pynfs/