Кросс-платформенный IPC
Я ищу предложения по возможным механизмам IPC, которые являются:
кросс-платформенный (Win32 и Linux, по крайней мере)- простота реализации в C++ а также наиболее распространенные языки сценариев (perl, ruby, python и др.).
- наконец, прост в использовании С точки зрения программирования!
какие у меня варианты? Я программирую под Linux, но мне бы хотелось, чтобы я напишите, чтобы быть переносимым на другие ОС в будущем. Я думал об использовании сокетов, именованных каналов или чего-то вроде DBus.
16 ответов:
по отоношению к скорости, самый лучший кросс-платформенный механизм ИПК будет трубами. Это предполагает, однако, что вы хотите кросс-платформенный IPC на той же машине. Если вы хотите иметь возможность общаться с процессами на удаленных машинах, вы хотите посмотреть на использование сокетов вместо этого. К счастью, если вы говорите о TCP, по крайней мере, сокеты и каналы ведут себя примерно так же. Хотя API для их настройки и подключения различны, они оба просто действуют как потоки данные.
трудная часть, однако, не канал связи, а сообщения, которые вы передаете по нему. Вы действительно хотите посмотреть на то, что будет выполнять проверку и анализ для вас. Я рекомендую посмотреть на Google Протокол Буферы. Вы в основном создаете файл спецификации, который описывает объект, который вы хотите передать между процессами, и есть компилятор, который генерирует код на нескольких разных языках для чтения и записи объектов, которые соответствуют спекуляция. Это намного проще (и менее подвержено ошибкам), чем пытаться придумать протокол обмена сообщениями и парсер самостоятельно.
для C++, проверьте повысить IPC.
Возможно, вы также можете создать или найти некоторые привязки для языков сценариев.в противном случае, если это действительно важно, чтобы иметь возможность взаимодействовать с языками сценариев ваш лучший выбор-это просто использовать файлы, каналы или сокеты или даже абстракции более высокого уровня, такие как HTTP.
Почему не D-Bus? Это очень простая система передачи сообщений, которая работает практически на всех платформах и предназначена для обеспечения надежности. На данный момент он поддерживается практически каждым языком сценариев.
вы можете попробовать ями , это очень простой, но функциональный, портативный и поставляется с привязкой к несколько языков
если вы хотите портативный, простой в использовании, многоязычный и LGPLed решение, я бы рекомендовал вам ZeroMQ:
- удивительно быстрый, почти линейный масштабируемый и все еще простой.
- подходит для простых и сложных систем с архитектурой.
- очень мощные модели коммуникации в наличии: рэп-рэп, двухтактный, паб-саб, пара-пара.
- вы можете настроить транспортный протокол, чтобы сделать его более эффективным, если вы передаете сообщения между потоками (
inproc://), процессы (ipc://) или машины ({tcp|pgm|epgm}://), с умным вариантом для того чтобы сбрить некоторую часть накладных расходов протокола в случае соединений бежит между виртуальными машинами VMware (vmci://).для сериализации я бы предложил MessagePack или буферы протокола (которые другие уже упоминали также), в зависимости от вашего по необходимости.
как о бережливость Facebook?
бережливость-это программная платформа для масштабируемых кросс-языкового развития. Он сочетает в себе программный стек с механизмом генерации кода для создания служб, которые работают эффективно и плавно между C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk и OCaml.
Я думаю, что вы хотите, что-то на основе сокетов.
Если вы хотите RPC, а не просто IPC, я бы предложил что-то вроде XML-RPC/SOAP, который работает через HTTP и может использоваться с любого языка.
YAMI-еще одна инфраструктура обмена сообщениями это легкий обмен сообщениями и сетевая структура.
Если вы готовы попробовать что-то немного другое, есть лед С ZeroC. Он с открытым исходным кодом и поддерживается практически на каждой ОС, о которой вы можете думать, а также имеет языковую поддержку для C++, C#, Java, Ruby, Python и PHP. Наконец, это очень легко управлять (языковые сопоставления адаптированы, чтобы естественно вписаться в каждый язык). Это также быстро и эффективно. Есть даже урезанная версия для устройств.
распределенные вычисления обычно сложны, и вам рекомендуется использовать существующие библиотеки или фреймворки вместо того, чтобы изобретать колесо. Предыдущий плакат уже перечислил несколько таких библиотек и фреймворков. В зависимости от ваших потребностей вы можете выбрать либо очень низкий уровень (например, сокеты), либо фреймворк высокого уровня (например, CORBA). Не может быть общего ответа "использовать это". Вам нужно обучить себя распределенному программированию, а затем будет намного проще выбрать правильная библиотека или фреймворк для задания.
существует дико используемая платформа C++ для распределенных вычислений, называемая ACE и CORBA ORB TAO (которая построена на ACE). Существуют очень хорошие книги о ACEhttp://www.cs.wustl.edu/~schmidt / ACE/ так что вы можете взглянуть. Берегите себя!
Это не становится более простым, чем использование труб, которые поддерживаются на каждой ОС, о которой я знаю, и могут быть доступны практически на каждом языке.
проверить этой учебник.
Я могу предложить вам использовать plibsys библиотеки C. Это очень простой, легкий и кросс-платформенный. Выпущенный под LGPL. Он обеспечивает:
- именованные общесистемные области общей памяти (реализации System V, POSIX и Windows);
- именованные общесистемные семафоры для синхронизации доступа (реализации System V, POSIX и Windows);
- именованная общесистемная реализация общего буфера на основе общей памяти и семафор;
- сокеты (TCP, UDP, SCTP) с поддержкой IPv4 и IPv6 (реализации UNIX и Windows).
Это простая в использовании библиотека с довольно хорошей документацией. Как написано в C вы можете легко сделать привязки из языков сценариев.
Если вам нужно передать большие наборы данных между процессами (особенно если скорость важна), лучше использовать общую память для передачи самих данных и сокетов, чтобы уведомить процесс о том, что данные готовы. Вы можете сделать это следующим образом:
- процесс помещает данные в сегмент общей памяти и отправляет уведомление через сокет другому процессу; поскольку уведомление обычно очень мало, временные затраты минимальны;
- другой процесс получает уведомление и считывает данные из сегмента общей памяти; после этого он отправляет уведомление о том, что данные были считаны обратно в первый процесс, чтобы он мог подавать больше данных.
этот подход может быть реализован в кросс-платформенном режиме.
Python имеет довольно хорошую библиотеку IPC: см. https://docs.python.org/2/library/ipc.html
Xojo имеет встроенную кросс-платформенную поддержку IPC с его класс IPCSocket. Хотя вы, очевидно, не могли "реализовать" его на других языках, вы можете использовать его в консольном приложении Xojo и вызывать его с других языков, что делает этот вариант, возможно, очень простым для вас.
Google protobufs-это действительно плохая идея, когда вы хотите легко поддерживать и отлаживать код. его слишком легко для людей, чтобы злоупотреблять им и использовать его, чтобы загрязнить ваш код. файлы proto хороши, но в основном это то же самое, что и файл заголовка структуры, и код, который он генерирует, является полным дерьмом, заставляющим вас задаться вопросом, действительно ли это скрытый инструмент атаки для саботажа программных проектов вместо их автоматизации. После того, как вы используете его в течение некоторого времени его почти невозможно удалить из вашего кода. ты лучше просто использовать заголовочный файл структур формата fix, которые легко отлаживаются.
Если вам действительно нужно сжатие, переключитесь на отображение адреса/данных файловых структур удаленно... тогда пакеты-это просто набор пар адрес / данные... также структура, которую очень легко автоматизировать с помощью собственных скриптов perl, которые производят код, который читается человеком и отлаживается
Comments