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

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

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

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

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

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

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

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

> Насколько я понимаю, и 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++ (но там было пару багов с педениями, которые пришлось вручную править).

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

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

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

Простой и мощный ORB: Ice, http://zeroc.com/

> Простой и мощный ORB: Ice, http://zeroc.com/

Он до сих пор под "заразной" GPL?

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

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

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


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