LINUX.ORG.RU
Форум — Development  

Подскажите, какую библиотеку RPC использовать


0

0

Встал вопрос выбора библиотеки для реализации RPC в моей программе.

Что бы хотелось:
* Биндинги к C++.
* Адекватная документация.
* Чтобы работала через обычный TCP и, желательно, чтобы, если требуется работать только на одном компьютере, использовала UNIX сокеты.

Буду рад любому совету или ссылке на какой-нибудь обзор.

Вообще, на первый вгляд, если использовать самые распространенные решения, то, вроде бы, выбор остается только за xml-rpc и DBus.

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

DBus удручает своей документацией и тем, что, насколько я понял, нормально с ним можно работать только через системную шину (которую просто так не захватишь - необходимо предварительно прописать себе права в /etc/dbus-1/system.d/, что не есть гут). Работа через сессионную шину - вообще сплошной геморрой: оказывается, далеко не во всех дистрибутивах иксы создают эту саму сессионную шину + если пользователь сдуру запустит в терминале новую сессию, то ее никто не увидит, т. к. все остальные приложения будут находиться вдругой сессии. Про TCP в документации вообще ни слова кроме ссылки на man dbus-daemon.

Вообщем, надеюсь на вашу помощь.

P.S.: или, может быть, плюнуть на все это и вручную написать на сокетах? :)


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

Та лол, думаешь, через дубас гигазы данных будут гоняться быстрее? RPC не для этого придуманы.

tomodachi_ni_narimashou
()

> или, может быть, плюнуть на все это и вручную написать на сокетах? :)

да, сделай так, если не понимаешь зачем нужен XMLRPC и зачем DBus

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

> Та лол, думаешь, через дубас гигазы данных будут гоняться быстрее? RPC не для этого придуманы.
Я и не говорю о гигабайтах данных. Ну вот возьмем для примера deluge. Он, насколько я знаю, использует xml-rpc. Весь гуй обновляется через него, причем обновляется, допустим, раз в секунду. Возьмем ситуацию, когда у нас ~1000 торрентов: каждую секунду придется передавать информацию о них, упаковывая все это дело в XML (можно, конечно, сделать "diff", но это не всегда реально). Бинарный протокол уж точно будет по-быстрее (представьте, что бы было, если бы Xorg работал через xml-rpc).

riYu
() автор топика
Ответ на: комментарий от phasma

> да, сделай так, если не понимаешь зачем нужен XMLRPC и зачем DBus
Насколько я понимаю, и XMLRPC и DBus нужны в частности для того, чтобы позволить программисту разделить программу на две части, которые могут быть запущены на разных машинах. Я не прав?

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

> Насколько я понимаю, и XMLRPC и DBus нужны в частности для того, чтобы позволить программисту разделить программу на две части, которые могут быть запущены на разных машинах. Я не прав?

Если упростить - то XMLRPC удобен тем, что тебе не важно на чем написан клиент(-ы) и сервер(-а). Ты просто имеешь один унифицированый интерфейс.

Допустим ты сделал веб сервис на с++ и клиент на mono. Но потом решил перепесать с mono на java. При этом тебе не надо менять протокол. И даже его писать. Ты просто берешь либу xmlrpc и работаешь с сервисом.

Но потом тебе надо подключить уже готовое решение - сервис написаный на перле. Если он тоже предоставляет такой интерфейс - ты не сильно меняя логику клиентов - добавляешь его в свою программу.

Но кроме xmlrpc есть ещё много разных стандартных протоколов, к примеру: REST (http://en.wikipedia.org/wiki/Representational_State_Transfer), SOAP (http://en.wikipedia.org/wiki/SOAP). Некоторые даже делают сервисы с протоколом memcached (memcachedb к примеру - http://memcachedb.org/).

Для с++ я когдато использовать xmlrpc++ (но там было пару багов с педениями, которые пришлось вручную править).

stpg ★
()

dbus говно(имхо :)), юзать его в сетевой среде даже сами разрабы не рекомендуют. Ни о какой аутентификации и шифровании и речи не идёт. И вообще это какая-то малопонятная хрень на которую потратишь кучу времени чтобы разобраться.

У гугла есть protocol buffers который они рекомендуют юзать(ещё бы:)), но я его так и не тестил. Если потестишь-отпиши плиз по результатам.

Вообще, есть куча всяких шин, я даже велосипед свой почти написал(распределённая, работало по udp, с контролем доставки сообщений, автодискавери нод, ретрансляция сообщений через прокси итп), но потом надобность в этом отпала и я забил. В качестве сериализатора как раз брал сановскую rpc-либу. Не смотря на то что ей очень много лет оно работает и поддерживается в libc :)

true_admin ★★★★★
()

> boost.channel, например - http://channel.sourceforge.net/

> У гугла есть protocol buffers который они рекомендуют юзать(ещё бы:)), но я его так и не тестил. Если потестишь-отпиши плиз по результатам.

Спасибо, гляну.


> Простой и мощный ORB: Ice, http://zeroc.com/
Если на первый взгляд, то документация производит хорошее впечатление - может быть, это действительно то, что нужно. Спасибо.

riYu
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development