Какой метод Linux IPC использовать?
Мы все еще находимся на стадии разработки нашего проекта, но мы думаем о том, чтобы иметь три отдельных процесса во встроенном ядре Linux. Одним из процессов является коммуникационный модуль, который обрабатывает все коммуникации с устройством через различные носители.
Два других процесса должны будут иметь возможность отправлять / получать сообщения через процесс связи. Я пытаюсь оценить методы IPC, которые предоставляет Linux; сообщение, которое будут отправлять другие процессы, будет различаться по размеру, от журналов отладки до потокового мультимедиа со скоростью ~5 Мбит. Кроме того, медиа могут передаваться и передаваться одновременно.
Какой метод IPC вы бы предложили для этого приложения? http://en.wikipedia.org/wiki/Inter-process_communication
Процессор работает на частоте 400-500 МГц, если это что-то меняет. Не нужно быть кроссплатформенным, только Linux в порядке. Реализация на C или C++ обязательна.
5 ответов
Я бы выбрал Unix Domain Sockets: меньше накладных расходов, чем IP-сокеты (то есть нет межмашинных коммуникаций), но то же удобство в противном случае.
When selecting your IPC you should consider causes for performance differences including transfer buffer sizes, data transfer mechanisms, memory allocation schemes, locking mechanism implementations, and even code complexity.
Of the available IPC mechanisms, the choice for performance often comes down to Unix domain sockets or named pipes (FIFOs). I read a paper on Performance Analysis of Various Mechanisms for Inter-process Communication that indicates Unix domain sockets for IPC may provide the best performance. I have seen conflicting results elsewhere which indicate pipes may be better.
При отправке небольших объемов данных я предпочитаю именованные каналы (FIFO) для их простоты. Это требует пары именованных каналов для двунаправленной связи. Доменные сокеты Unix требуют немного больше ресурсов при настройке (создание сокетов, инициализация и подключение), но они более гибкие и могут предложить более высокую производительность (более высокую пропускную способность).
Возможно, вам придется запустить некоторые тесты для вашего конкретного приложения / среды, чтобы определить, что будет работать лучше для вас. Из приведенного описания видно, что доменные сокеты Unix могут подойти лучше всего.
Руководство Beej по Unix IPC хорошо для начала работы с Linux/Unix IPC.
Не могу поверить, что никто не упомянул dbus.
http://www.freedesktop.org/wiki/Software/dbus
http://en.wikipedia.org/wiki/D-Bus
Может быть, это немного излишне, если ваше приложение архитектурно просто, и в этом случае - в управляемой встроенной среде, где производительность имеет решающее значение - вы не можете превзойти общую память.
Если производительность действительно становится проблемой, вы можете использовать разделяемую память - но это намного сложнее, чем другие методы - вам понадобится механизм сигнализации для оповещения о готовности данных (семафор и т. Д.), А также блокировки для предотвращения одновременного доступа к структурам пока они меняются.
Положительным моментом является то, что вы можете передавать много данных без необходимости копировать их в память, что в некоторых случаях определенно улучшит производительность.
Возможно, есть полезные библиотеки, которые предоставляют примитивы более высокого уровня через разделяемую память.
Общая память обычно получается путем mmapping того же файла с помощью MAP_SHARED (который может быть на tmpfs, если вы не хотите, чтобы он сохранялся); многие приложения также используют разделяемую память System V (ИМХО по глупым историческим причинам; гораздо менее приятный интерфейс к тому же)
На момент написания статьи (ноябрь 2014 года) Kdbus и Binder покинули промежуточную ветвь ядра Linux. На данный момент нет никаких гарантий, что кто-либо из них это сделает, но перспективы для обоих несколько позитивны. Binder - это облегченный механизм IPC в Android, Kdbus - это подобный dbus механизм IPC в ядре, который уменьшает переключение контекста, тем самым значительно ускоряя обмен сообщениями.
Существует также "Прозрачная межпроцессная связь" или TIPC, которая является надежной, полезной для кластеризации и настройки нескольких узлов; http://tipc.sourceforge.net/
Доменные сокеты Unix будут соответствовать большинству ваших требований IPC. В этом случае вам не нужен специальный процесс связи, поскольку ядро предоставляет эту возможность IPC. Кроме того, обратите внимание на очереди сообщений POSIX, которые, по моему мнению, являются одним из наиболее малоиспользуемых IPC в Linux, но очень удобны во многих случаях, когда необходимы коммуникации n:1.