Какой метод Linux IPC использовать?

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

Другие два процесса должны будут иметь возможность отправлять/получать сообщения через процесс связи. Я пытаюсь оценить методы IPC, которые предоставляет Linux; сообщение, отправляемое другими процессами, будет отличаться по размеру: от журналов отладки до потокового медиа со скоростью ~ 5 Мбит. Кроме того, средства массовой информации могут одновременно транслироваться.

Какой метод IPC вы бы предложили для этого приложения? http://en.wikipedia.org/wiki/Inter-process_communication

Процессор работает на 400-500 МГц, если это что-то изменит. Не нужно быть кросс-платформенным, Linux только в порядке. Реализация на C или С++ требуется.

Ответ 1

Я бы пошел на Unix-доменные сокеты: меньше накладных расходов, чем IP-сокеты (т.е. межмашинная связь), но в то же самое удобство.

Ответ 2

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

Из доступных механизмов IPC выбор производительности часто сводится к сокетам домена Unix или именованным каналам (FIFO). Я прочитал статью " Анализ производительности различных механизмов межпроцессного взаимодействия", в которой указано, что доменные сокеты Unix для IPC могут обеспечить наилучшую производительность. Я видел противоречивые результаты в другом месте, которые указывают, что трубы могут быть лучше.

При отправке небольших объемов данных я предпочитаю именованные каналы (FIFO) за их простоту. Это требует пары именованных каналов для двунаправленной связи. Доменные сокеты Unix требуют немного больше ресурсов при настройке (создание сокетов, инициализация и подключение), но они более гибкие и могут предложить более высокую производительность (более высокую пропускную способность).

Возможно, вам придется запустить некоторые тесты для вашего конкретного приложения/среды, чтобы определить, что будет работать лучше для вас. Из приведенного описания видно, что доменные сокеты Unix могут подойти лучше всего.

Руководство Beej по Unix IPC хорошо для начала работы с Linux/Unix IPC.

Ответ 3

Не могу поверить, что никто не упомянул dbus.

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

http://en.wikipedia.org/wiki/D-Bus

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

Ответ 4

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

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

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

Общая память обычно получается путем mmaping того же файла, используя MAP_SHARED (который может быть на tmpfs, если вы не хотите, чтобы он сохранялся); многие приложения также используют общую память System V (IMHO для глупых исторических причин, это гораздо менее приятный интерфейс для одного и того же)

Ответ 5

Обзор "классических" механизмов IPC Linux: см. здесь.

Ответ 6

На момент написания статьи (ноябрь 2014 года) Kdbus и Binder покинули промежуточную ветвь ядра linux. На данный момент нет никакой гарантии, что либо это произойдет, но перспектива несколько положительна для обоих. Binder - это легкий механизм IPC в Android, Kdbus - это механизм IPC, подобный dbus, в ядре, который уменьшает контекстный переключатель, тем самым значительно ускоряя обмен сообщениями.

Существует также "Прозрачная межпроцессная связь" или TIPC, которая является надежной, полезной для кластеризации и множества node настроек; http://tipc.sourceforge.net/

Ответ 7

Доменные сокеты Unix будут соответствовать большинству ваших требований IPC. В этом случае вам не нужен специальный процесс связи, поскольку ядро предоставляет эту возможность IPC. Кроме того, обратите внимание на очереди сообщений POSIX, которые, по моему мнению, являются одними из самых недоиспользуемых IPC в Linux, но во многих случаях очень удобны.