Russian Qt Forum
Август 07, 2020, 16:10 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1]   Вниз
  Печать  
Автор Тема: межпроцессное взаимодействие  (Прочитано 6975 раз)
leonike
Гость
« : Май 07, 2011, 11:51 »

Привет всем. Возник такой вопрос.
Необходимо реализовать интерфейс для взаимодействия с другими программами (т.е. другие программы смогут использовать функционал моей программы). В Linux это можно сделать посредством dbus. Есть ли кроссплатформенный инструмент или придется пилить реализацию для каждой операционки отдельно? Если нет, какие инструменты посоветуете для linux, windows, mac os?
Записан
asvil
Гость
« Ответ #1 : Май 07, 2011, 12:27 »

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

Записан
merke
Гость
« Ответ #2 : Май 07, 2011, 12:39 »

Pipe - QLocalServer, QLocalSocket; QSharedMemory
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 10834


Просмотр профиля
« Ответ #3 : Май 07, 2011, 15:08 »

Многое зависит от того должны ли 32 и 64-битные приложения общаться между собой. Если все "только 32" (или только 64), то просто dll (dylib). Если же "смешанный" вариант, то сложнее - либо на сокетах, либо (если нужна скорость) на семафорах и shared memory
Записан
merke
Гость
« Ответ #4 : Май 07, 2011, 17:31 »

А можно поподробнее об этом? О таком я ещё не слышал
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 10834


Просмотр профиля
« Ответ #5 : Май 08, 2011, 08:53 »

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

Сообщений: 296



Просмотр профиля
« Ответ #6 : Май 21, 2011, 22:17 »

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

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

Qt 5.11.0, Win, MinGW
ddrtn
Гость
« Ответ #7 : Июнь 02, 2011, 08:56 »

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

Сообщений: 1019


С уважением, мастер конфетного цеха!


Просмотр профиля
« Ответ #8 : Июнь 03, 2011, 15:24 »

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

kuzulis
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2734


Просмотр профиля
« Ответ #9 : Июнь 03, 2011, 15:57 »

В свое время для реализации общения демона с ГУИ использовал RPC вот отсюда http://deltavsoft.com/w/ довольно удобно, но придется еще и boost к проекту подключать. Сам не в курсе ,но интересно ,а QtDBus не подойдет ?
Нет, в винде с ним проблемы. ИМХО, проще QLocalSocket/Server (как выше советовали).
Записан

ArchLinux x86_64 / Win10 64 bit
lesav
Частый гость
***
Offline Offline

Сообщений: 235


qnx.org.ru


Просмотр профиля WWW
« Ответ #10 : Июнь 03, 2011, 20:11 »

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

lesav
Частый гость
***
Offline Offline

Сообщений: 235


qnx.org.ru


Просмотр профиля WWW
« Ответ #11 : Июнь 04, 2011, 09:55 »

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

merke
Гость
« Ответ #12 : Июнь 04, 2011, 11:08 »

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

Сообщений: 235


qnx.org.ru


Просмотр профиля WWW
« Ответ #13 : Июнь 05, 2011, 07:59 »

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

Страниц: [1]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.053 секунд. Запросов: 22.