Кроссплатформенный IPC
https://stackoverflow.com/questions/60649
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я ищу предложения по возможным механизмам IPC, которые:
- Кросс-платформа (по крайней мере, Win32 и Linux)
- Просто реализовать в С++ так же хорошо как наиболее распространенные языки сценариев (perl, рубин, питон и т. д.).
- Окончательно, простой в использовании с точки зрения программирования!
Какие у меня есть варианты?Я программирую под Linux, но мне бы хотелось, чтобы то, что я пишу, в будущем можно было переносить на другие операционные системы.Я думал об использовании сокетов, именованных каналов или чего-то вроде DBus.
Решение
С точки зрения скорости лучшим кроссплатформенным механизмом IPC будут каналы.Однако это предполагает, что вам нужен кроссплатформенный IPC на одной машине.Если вы хотите иметь возможность общаться с процессами на удаленных машинах, вместо этого вам стоит рассмотреть возможность использования сокетов.К счастью, если вы говорите, по крайней мере, о TCP, сокеты и каналы ведут себя примерно одинаково.Хотя API для их настройки и подключения различны, оба они действуют как потоки данных.
Однако трудность заключается не в канале связи, а в сообщениях, которые вы по нему передаете.Вы действительно хотите посмотреть на что-то, что выполнит за вас проверку и анализ.Рекомендую посмотреть Google Буферы протоколов.По сути, вы создаете файл спецификации, описывающий объект, который хотите передать между процессами, и есть компилятор, который генерирует код на нескольких разных языках для чтения и записи объектов, соответствующих спецификации.Это намного проще (и менее подвержено ошибкам), чем пытаться придумать протокол обмена сообщениями и анализировать его самостоятельно.
Другие советы
Для C++ проверьте Повышение IPC.
Вероятно, вы также сможете создать или найти некоторые привязки для языков сценариев.
В противном случае, если действительно важно иметь возможность взаимодействовать с языками сценариев, лучше всего просто использовать файлы, каналы или сокеты или даже абстракцию более высокого уровня, например HTTP.
Почему не D-Bus?Это очень простая система передачи сообщений, которая работает практически на всех платформах и отличается надежностью.На данный момент он поддерживается практически всеми языками сценариев.
Возможно, вы захотите попробовать ЯМИ , он очень простой, но функциональный, портативный и имеет привязку к нескольким языкам.
Если вам нужен портативный, простой в использовании, многоязычный и LGPLрешение, я бы порекомендовал вам НольMQ:
- Удивительно быстрый, почти линейный масштабируемый и при этом простой.
- Подходит для простых и сложных систем/архитектур.
- Доступны очень мощные шаблоны общения:ПОВТОР-ПОВТОР, ПУШ-ПУЛЛ, ПАБ-СУБ, ПАРА-ПАРА.
- Вы можете настроить транспортный протокол, чтобы сделать его более эффективным при передаче сообщений между потоками (
inproc://), процессы (ipc://) или машины ({tcp|pgm|epgm}://), с умной опцией, позволяющей снизить часть накладных расходов протокола в случае, если соединения выполняются между виртуальными машинами VMware (vmci://).
Для сериализации я бы предложил Пакет сообщений или протокольные буферы (о которых уже упоминалось), в зависимости от ваших потребностей.
Как насчет Бережливость Facebook?
Thrift — это программная платформа для разработки масштабируемых межъязыковых сервисов.Он сочетает в себе стек программного обеспечения с механизмом генерации кода для создания сервисов, которые эффективно и бесперебойно работают между C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk и OCaml.
Я думаю, вам понадобится что-нибудь на основе сокетов.
Если вам нужен RPC, а не просто IPC, я бы предложил что-то вроде XML-RPC/SOAP, который работает через HTTP и может использоваться на любом языке.
YAMI — еще одна инфраструктура обмена сообщениями представляет собой облегченную среду обмена сообщениями и сети.
Если вы хотите попробовать что-то немного другое, есть ЛЕД платформа из ЗероС.Он имеет открытый исходный код и поддерживается практически во всех ОС, о которых вы только можете подумать, а также имеет языковую поддержку C++, C#, Java, Ruby, Python и PHP.Наконец, им очень легко управлять (языковые сопоставления адаптированы для естественного соответствия каждому языку).Это также быстро и эффективно.Есть даже урезанная версия для устройств.
Я могу предложить вам использовать плибсис библиотека С.Он очень простой, легкий и кроссплатформенный.Выпущено под лицензией LGPL.Это обеспечивает:
- именованные общесистемные области общей памяти (реализации System V, POSIX и Windows);
- именованные общесистемные семафоры для синхронизации доступа (реализации System V, POSIX и Windows);
- реализация именованного общесистемного общего буфера на основе общей памяти и семафора;
- сокеты (TCP, UDP, SCTP) с поддержкой IPv4 и IPv6 (реализации UNIX и Windows).
Это простая в использовании библиотека с неплохой документацией.Поскольку он написан на C, вы можете легко создавать привязки из языков сценариев.
Если вам необходимо передавать большие наборы данных между процессами (особенно если важна скорость), лучше использовать общую память для передачи самих данных и сокеты для уведомления процесса о готовности данных.Вы можете сделать это следующим образом:
- процесс помещает данные в сегмент общей памяти и отправляет уведомление через сокет другому процессу;поскольку уведомление обычно очень маленькое, затраты времени минимальны;
- другой процесс получает уведомление и считывает данные из сегмента общей памяти;после этого он отправляет уведомление о том, что данные были прочитаны обратно в первый процесс, чтобы он мог передать больше данных.
Этот подход может быть реализован кроссплатформенным способом.
Распределенные вычисления обычно сложны, и вам рекомендуется использовать существующие библиотеки или платформы, а не изобретать велосипед.Предыдущий постер уже перечислил пару таких библиотек и фреймворков.В зависимости от ваших потребностей вы можете выбрать структуру очень низкого уровня (например, сокеты) или структуру высокого уровня (например, CORBA).Не может быть общего ответа «используйте это».Вам необходимо изучить распределенное программирование, и тогда вам будет намного проще выбрать подходящую библиотеку или платформу для работы.
Существует широко используемая среда C++ для распределенных вычислений, называемая ACE и CORBA ORB TAO (основанная на ACE).Есть очень хорошие книги об ACE. http://www.cs.wustl.edu/~schmidt/ACE/ так что, возможно, вы посмотрите.Заботиться!
Нет ничего проще, чем использовать каналы, которые поддерживаются во всех известных мне ОС и доступны практически на любом языке.
Проверить этот руководство.
TCP-сокеты для локального хоста FTW.
Python имеет довольно хорошую библиотеку IPC:видеть https://docs.python.org/2/library/ipc.html
Xojo имеет встроенную кроссплатформенную поддержку IPC с помощью Класс IPCSocket.Хотя вы, очевидно, не можете «реализовать» его на других языках, вы можете использовать его в консольном приложении Xojo и вызывать его с других языков, что, возможно, сделает этот вариант очень простым для вас.
Google protobufs — действительно плохая идея, поскольку вам нужно легко поддерживать и отлаживать код.людям слишком легко злоупотреблять им и использовать его для загрязнения вашего кода.Прото-файлы хороши, но по сути это то же самое, что и заголовочный файл структуры, а генерируемый им код — полная чушь, заставляющая задуматься, действительно ли это инструмент скрытой атаки, предназначенный для саботажа программных проектов, а не для их автоматизации.После некоторого использования его практически невозможно удалить из кода.вам лучше просто использовать заголовочный файл структур исправленного формата, который легко отлаживается.
если вам действительно нужно сжатие, переключитесь на удаленное сопоставление адресов/данных файловых структур...тогда пакеты представляют собой просто набор пар адрес/данные...также структура, которую очень легко автоматизировать с помощью собственных Perl-скриптов, создающих код, удобочитаемый и отлаживаемый человеком.
