межпроцессное взаимодействие

[leonike]

Привет всем. Возник такой вопрос.
Необходимо реализовать интерфейс для взаимодействия с другими программами (т.е. другие программы смогут использовать функционал моей программы). В Linux это можно сделать посредством dbus. Есть ли кроссплатформенный инструмент или придется пилить реализацию для каждой операционки отдельно? Если нет, какие инструменты посоветуете для linux, windows, mac os?

[asvil]

Если функции программа предоставляет интерфейс не имеющий состояний, то реализуете каждую функцию (или набор функций) в виде программы принимающей аргументы командной строки, с возвратом значения в stdout, ошибок в stderr.
А далее можно подумать и управление программой осуществлять через stdin, а не аргументами командной строки. Это значит, что Ваша задача сводится к написанию некоторого telnet сервера, которыми оснащаются сетевые устройства например. Автоматизированное управление данным сервером можно осуществлять сценариями командной строки клиентской операционной системы.
Впринципе крассплатформенность/сетевая прозрачность обеспечена. Защита передаваемых данных с помощью ssh.

[merke]

Pipe - QLocalServer, QLocalSocket; QSharedMemory

[Igors]

Многое зависит от того должны ли 32 и 64-битные приложения общаться между собой. Если все "только 32" (или только 64), то просто dll (dylib). Если же "смешанный" вариант, то сложнее - либо на сокетах, либо (если нужна скорость) на семафорах и shared memory

[merke]

А можно поподробнее об этом? О таком я ещё не слышал

[Igors]

А можно поподробнее об этом? О таком я ещё не слышал

Если это вопрос ко мне и по поводу 32/64 - то использовать dll (приятные во всех отношениях) не удается т.к. на любой платформе 32 хост не может звать 64 dll и наоборот. Простейший вариант для 2 приложений (32 и 64) - создать 2 shared семафора. Каждое приложение ждет на одном (возможно 1 ниткой) и сигналит по другому. Как только сигнал получен - данные забираются из shared memory.

[kolob]

с возвратом значения в stdout, ошибок в stderr.

Вопрос наверно немного не в тему. Но все же, подскажите как объединить вывод в file и stderr на консоль?

[ddrtn]

Если клиенты планируются только кутешные, то можно воспользоваться либой QXT. в ней реализован RPC протокол на основе механизма сигналов/слотов. там фактически сигнал передается другому процессу через QIODevice.
Для отвязки клиентов от Qt можно реализовать свой небольшой RPC сервис. я делал на базе Hessian.

[ecspertiza]

В свое время для реализации общения демона с ГУИ использовал RPC вот отсюда http://deltavsoft.com/w/ довольно удобно, но придется еще и boost к проекту подключать. Сам не в курсе ,но интересно ,а QtDBus не подойдет ?

[kuzulis]

В свое время для реализации общения демона с ГУИ использовал RPC вот отсюда http://deltavsoft.com/w/ довольно удобно, но придется еще и boost к проекту подключать. Сам не в курсе ,но интересно ,а QtDBus не подойдет ?

Нет, в винде с ним проблемы. ИМХО, проще QLocalSocket/Server (как выше советовали).

[lesav]

Делал подобное. Использовал UDP (Изначально не хотел привязываться к TCP)
В моем обмене нет больших объемов передаваемых данных. Ставка делалась на скорость (устройства используют GPRS).  Все данные перед отправкой сжимаются в qcompress. На принимающей стороне qUncompress.
Результатом доволен.

[lesav]

Забыл добавить: 
При отладке механизма обмена на локальной машине отметил, что такая методика оказалась удобной и для обмена командами/данными для межпроцессного взаимодействия (если убрать функционал сжатия трафика).

[merke]

Думаю если ещё и архивировать данные, это будет накладно. Да если просто команды то лучше не компресить их, а отправлять так как есть.

[lesav]

Безусловно!  Один 1-8 байт нет смысла сжимать. А вот 0,5 - 64 кб уже смысл есть, тем более если команды и данные передаются в ASCII символах.