Крест платформы IPC

Question

Я ищу предложения относительно возможных механизмов IPC, которые:

• Кроссплатформенный (Win32 и Linux, по крайней мере)
• Простой реализовать в C++, а также наиболее распространенные языки сценариев (perl, ruby, python и т. Д.).
• И, наконец, прост в использовании с точки зрения программирования!

Какие у меня варианты? Я программирую под Linux, но мне хотелось бы, чтобы я писал, чтобы переносить их в другие ОС в будущем. Я думал об использовании сокетов, названных каналов или что-то вроде DBus.

Answer 1

Что касается скорости, лучшим кросс-платформенным механизмом IPC будут трубы. Это предполагает, однако, что вы хотите, чтобы кросс-платформенный IPC на одном компьютере. Если вы хотите иметь возможность разговаривать с процессами на удаленных компьютерах, вы захотите посмотреть на использование сокетов вместо этого. К счастью, если вы говорите о TCP, по крайней мере, сокеты и трубы ведут себя примерно одинаково. Хотя API-интерфейсы для их настройки и подключения к ним разные, они оба действуют как потоки данных.

Трудная часть, однако, не является каналом связи, а сообщениями, которые вы передаете. Вы действительно хотите посмотреть на что-то, что будет выполнять проверку и синтаксический анализ для вас. Рекомендую посмотреть Protocol Buffers. Вы в основном создаете спецификационный файл, который описывает объект, который вы хотите передать между процессами, и есть компилятор, который генерирует код на нескольких разных языках для чтения и записи объектов, соответствующих спецификации. Это намного проще (и меньше подвержено ошибкам), чем пытаться придумать протокол обмена сообщениями и парсер самостоятельно.

Answer 2

Для C++, проверьте Boost IPC.
Возможно, вы можете создать или найти некоторые привязки для языков сценариев.

В противном случае, если действительно важно иметь возможность взаимодействовать с языками сценариев, лучше всего использовать файлы, трубы или сокеты или даже абстракцию более высокого уровня, такую ​​как HTTP.

Answer 3

Как насчет Facebook's Thrift?

Thrift - это программная среда для масштабируемых межязыковых сервисов. Он объединяет стек программного обеспечения с механизмом генерации кода для создания сервисов, которые работают эффективно и плавно между C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk и OCaml.

Answer 4

Это не так просто, как использование труб, которые поддерживаются в каждой ОС, о которой я знаю, и могут быть доступны практически на каждом языке.

Отъезд this учебник.

Answer 5

Сокеты TCP to localhost FTW.

Answer 6

Я думаю, что вы захотите что-то, основанное на сокетах.

Если вы хотите RPC, а не только IPC, я бы предложил что-то вроде XML-RPC/SOAP, которое работает через HTTP и может использоваться с любого языка.

Answer 7

Если вы хотите попробовать что-то совсем другое, есть платформа ICE от ZeroC. Это с открытым исходным кодом и поддерживается практически во всех ОС, о которых вы можете думать, а также в языковой поддержке C++, C#, Java, Ruby, Python и PHP. Наконец, он очень прост в управлении (языковые сопоставления адаптированы для естественного перехода на каждый язык). Это также быстро и эффективно. Для устройств есть даже сокращенная версия.

Answer 8

Вы могли бы хотеть попробовать YAMI, это очень простые, но функциональные, портативный и поставляется с привязкой к нескольким языкам

Answer 9

Почему не D-Bus? Это очень простая система передачи сообщений, которая работает практически на всех платформах и предназначена для обеспечения надежности. На данный момент это поддерживается почти каждым языком сценариев.

http://freedesktop.org/wiki/Software/dbus

Answer 10

Python имеет довольно хорошую библиотеку IPC: см https://docs.python.org/2/library/ipc.html

Answer 11

распределенных вычислений, как правило, сложны и вы хорошо рекомендуется использовать существующие библиотеки или рамки вместо того чтобы изобретать колесо. Предыдущий плакат уже перечислил пару этих библиотек и фреймворков. В зависимости от ваших потребностей вы можете выбрать очень низкий уровень (например, сокеты) или фреймворк высокого уровня (например, CORBA). Не может быть общего «использования этого» ответа. Вам нужно рассказать о распределенном программировании, и тогда вам будет намного легче выбрать нужную библиотеку или структуру для работы.

Существует дико используемая структура C++ для распределенных вычислений, называемая ACE и CORBA ORB TAO (которая основана на ACE). Существуют очень хорошие книги об ACE http://www.cs.wustl.edu/~schmidt/ACE/, чтобы вы могли взглянуть. Береги себя!

Answer 12

YAMI - Yet Another Messaging Infrastructure - это легкая система обмена сообщениями и сетей.

Answer 13

Возможно, вы захотите зарегистрироваться openbinder.

Answer 14

google protobufs - очень плохая идея, и вы хотите легко поддерживать и отлаживать код. это слишком легко для людей, чтобы злоупотреблять им и использовать его для загрязнения вашего кода. прото-файлы хороши, но в основном это то же самое, что и файл заголовка структуры, и код, который он генерирует, является полным дерьмом, заставляя вас задуматься, действительно ли это скрытый инструмент атаки для саботажа программных проектов вместо их автоматизации. После того, как вы используете его на некоторое время, его почти невозможно удалить из своего кода. вам лучше просто использовать заголовочный файл структур фиксированного формата, которые легко отлаживаются.

Если вам действительно нужно сжатие, переключитесь на сопоставление адресов/данных структур подачи удаленно ... , тогда пакеты - это всего лишь пакет пар адресов/данных ... также структура, которую очень легко автоматизировать с помощью собственные Perl скрипты, которые производят код, который является читаемым человеком и debugable

Answer 15

Если вы хотите портативный, легкий в использовании, многоязычные и LGPL решение Е.Д., я бы порекомендовал вам ZeroMQ:

• Удивительно быстро, почти линейная масштабируемость и все еще простая.
• Подходит для простых и сложных систем/архитектур.
• Имеются очень мощные коммуникационные модели: REP-REP, PUSH-PULL, PUB-SUB, PAIR-PAIR.
• Вы можете настроить транспортный протокол, чтобы сделать его более эффективным, если вы передаете сообщения между потоками (inproc://), процессы (ipc://) или машины ({tcp|pgm|epgm}://), с промежуточным сбрить какую-то часть накладных расходов протокола в случае соединений между виртуальными машинами VMware (vmci://).

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

Answer 16

Я могу предложить вам использовать библиотеку plibsys C. Это очень простой, легкий и кросс-платформенный. Выпущен под LGPL. Он обеспечивает:

• назвал области общей памяти общей системы (системы V, POSIX и Windows);
• назвал семафоры в масштабе всей системы для синхронизации доступа (версии System V, POSIX и Windows);
• назвал общую реализацию общего буфера на основе общей памяти и семафора;
• сокеты (TCP, UDP, SCTP) с поддержкой IPv4 и IPv6 (реализация UNIX и Windows).

Простая в использовании библиотека с неплохой документацией. Поскольку он написан на языке C, вы можете легко создавать привязки с языков сценариев.

Если вам необходимо передать большие наборы данных между процессами (особенно если скорость важна), лучше использовать общую память для передачи самих данных и сокетов, чтобы уведомить процесс о готовности данных. Вы можете сделать это следующим образом:

• процесс переносит данные в сегмент разделяемой памяти и отправляет уведомление через сокет другому процессу; поскольку уведомление обычно очень мало, время накладные расходы минимальны;
• другой процесс получает уведомление и считывает данные из сегмента разделяемой памяти; после этого он отправляет уведомление о том, что данные были прочитаны обратно в первый процесс, чтобы он мог подавать больше данных.

Этот подход может быть реализован кросс-платформенным способом.