Я ищу предложения о возможных механизмах МПК, которые:
Какие у меня варианты? Я программирую под Linux, но мне хотелось бы, чтобы я писал, чтобы переносить их в другие ОС в будущем. Я думал об использовании сокетов, именованных каналов или что-то вроде DBus.
В плане скорости лучшим кросс-платформенным механизмом IPC будут трубы. Это предполагает, однако, что вы хотите, чтобы кросс-платформенный IPC на одном компьютере. Если вы хотите иметь возможность разговаривать с процессами на удаленных компьютерах, вы захотите посмотреть на использование сокетов вместо этого. К счастью, если вы говорите о TCP, по крайней мере, сокеты и трубы ведут себя примерно одинаково. Хотя API-интерфейсы для их настройки и подключения к ним различны, они оба действуют как потоки данных.
Однако сложная часть - это не канал связи, а сообщения, которые вы передаете. Вы действительно хотите посмотреть на что-то, что будет выполнять проверку и синтаксический анализ для вас. Я рекомендую посмотреть Буферы протоколов. Вы в основном создаете спецификационный файл, который описывает объект, который вы хотите передать между процессами, и есть компилятор, который генерирует код на нескольких разных языках для чтения и записи объектов, соответствующих спецификации. Это намного проще (и меньше подвержено ошибкам), чем пытаться придумать протокол обмена сообщениями и парсер.
Для С++, проверьте Boost IPC.
Возможно, вы можете создать или найти некоторые привязки для языков сценариев.
В противном случае, если действительно важно иметь возможность взаимодействовать с языками сценариев, лучше всего использовать файлы, трубы или сокеты или даже абстракцию более высокого уровня, например HTTP.
Почему бы не D-Bus? Это очень простая система передачи сообщений, которая работает практически на всех платформах и предназначена для обеспечения надежности. На этом этапе поддерживается почти каждый язык сценариев.
Возможно, вы захотите попробовать YAMI, он очень простой, но функциональный, портативный и поставляется с привязкой к несколько языков
Как насчет Facebook Thrift?
Thrift - это программная среда для масштабируемых межязыковых сервисов. Он объединяет стек программного обеспечения с механизмом генерации кода для создания сервисов, которые работают эффективно и плавно между С++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, С#, Cocoa, Smalltalk и OCaml.
Я думаю, вам нужно что-то, основанное на сокетах.
Если вы хотите RPC, а не только IPC, я бы предложил что-то вроде XML-RPC/SOAP, которое работает через HTTP и может использоваться с любого языка.
Сокеты TCP для локального FTW.
Если вы хотите попробовать что-то немного другое, там ICE платформа ZeroC. Он работает с открытым исходным кодом и поддерживается практически во всех ОС, о которых вы можете думать, а также в языковой поддержке С++, С#, Java, Ruby, Python и PHP. Наконец, он очень прост в управлении (языковые сопоставления адаптированы для естественного перехода на каждый язык). Это также быстро и эффективно. Там даже вырезанная версия для устройств.
Если вы хотите иметь портативное, простое в использовании, многоязычное и LGPL, я бы рекомендовал вам ZeroMQ:
inproc://), процессы ( ipc://) или машины ( {tcp|pgm|epgm}://), с умной опцией, чтобы сбрить часть служебных сообщений протокола, если соединения выполняются между виртуальными машинами VMware ( vmci://).Для сериализации я бы предложил MessagePack или протокольные буферы (о которых уже упоминалось другое), в зависимости от ваших потребностей.
Он не становится более простым, чем использование труб, которые поддерживаются в каждой ОС, о которой я знаю, и к ним можно получить доступ практически на любом языке.
Ознакомьтесь с этим учебником.
Распределенные вычисления обычно сложны, и вам рекомендуется использовать существующие библиотеки или фреймворки вместо того, чтобы изобретать колесо. Предыдущий плакат уже перечислил пару этих библиотек и фреймворков. В зависимости от ваших потребностей вы можете выбрать очень низкий уровень (например, сокеты) или фреймворк высокого уровня (например, CORBA). Не может быть общего "использования этого" ответа. Вам нужно рассказать о распределенном программировании, а затем найти гораздо легче выбрать правильную библиотеку или фреймворк для работы.
Существует дико используемая структура С++ для распределенных вычислений, называемая ACE и CORBA ORB TAO (которая основана на ACE). Существуют очень хорошие книги об ACE http://www.cs.wustl.edu/~schmidt/ACE/, чтобы вы могли взглянуть. Будьте осторожны!
YAMI - Еще одна инфраструктура обмена сообщениями - это легкая система обмена сообщениями и сети.
Я могу предложить вам использовать библиотеку plibsys C. Это очень простой, легкий и кросс-платформенный. Выпущен под LGPL. Он обеспечивает:
Простая в использовании библиотека с неплохой документацией. Поскольку он написан на языке C, вы можете легко создавать привязки с языков сценариев.
Если вам нужно передать большие наборы данных между процессами (особенно если скорость важна), лучше использовать общую память для передачи самих данных и сокетов, чтобы уведомить процесс о готовности данных. Вы можете сделать это следующим образом:
Этот подход может быть реализован кросс-платформенным способом.
Python имеет довольно хорошую библиотеку IPC: см. https://docs.python.org/2/library/ipc.html
Возможно, вы захотите проверить openbinder.
goob protobufs - очень плохая идея, и вы хотите легко поддерживать и отлаживать код. это слишком легко для людей, чтобы злоупотреблять им и использовать его для загрязнения вашего кода. прото файлы хороши, но в основном это то же самое, что и файл заголовка структуры, и код, который он генерирует, является полным дерьмом, заставляя вас задуматься, действительно ли это скрытый инструмент атаки для саботажа программных проектов вместо их автоматизации. После того, как вы используете его на некоторое время, его почти невозможно удалить из своего кода. вам лучше просто использовать заголовочный файл структур фиксированного формата, которые легко отлаживаются.
если вам действительно нужно сжатие, дистанционно переключайтесь на сопоставление адресов/данных структуры записей... то пакеты - это просто набор пар адресов/данных... также структура, которую очень легко автоматизировать с помощью собственных скриптов perl, которые создают код, который является читабельным человеком и отлаживаемым