¿Qué técnica de Linux IPC usar?

Question

Todavía estamos en la fase de diseño de nuestro proyecto, pero estamos pensando en tener tres procesos separados en un kernel de Linux incrustado. Uno de los procesos es un módulo de comunicaciones que maneja todas las comunicaciones hacia y desde el dispositivo a través de varios medios.

Los otros dos procesos necesitarán poder enviar/recibir mensajes a través del proceso de comunicación. Estoy tratando de evaluar las técnicas de IPC que proporciona Linux; el mensaje que enviarán los otros procesos variará en tamaño, desde los registros de depuración hasta los medios de transmisión a una velocidad de ~ 5 Mbit. Además, los medios podrían estar entrando y saliendo simultáneamente.

¿Qué técnica de IPC recomendaría para esta aplicación? http://en.wikipedia.org/wiki/Inter-process_communication

El procesador se ejecuta alrededor de 400-500 Mhz si eso cambia algo. No necesita ser multiplataforma, Linux solo está bien. Se requiere la implementación en C o C++.

Answer 1

Me gustaría utilizar Sockets de dominio Unix: menos sobrecarga que los enchufes de IP (es decir, sin intercomunicadores) pero la misma conveniencia de lo contrario.

Answer 2

Para una revisión de los mecanismos "clásicos" de Linux IPC: ver here.

Answer 3

Al seleccionar su IPC, debe tener en cuenta las diferencias de rendimiento, incluidos los tamaños de búfer de transferencia, los mecanismos de transferencia de datos, los esquemas de asignación de memoria, las implementaciones de mecanismos de bloqueo e incluso la complejidad del código.

De los mecanismos IPC disponibles, la elección del rendimiento a menudo se reduce a Unix domain sockets o named pipes (FIFOs). Leí un documento en Performance Analysis of Various Mechanisms for Inter-process Communication que indica que los sockets de dominio de Unix para IPC pueden proporcionar el mejor rendimiento. He visto resultados conflictivos elsewhere que indican que las tuberías pueden ser mejores.

Al enviar pequeñas cantidades de datos, prefiero los pipes con nombre (FIFO) por su simplicidad. Esto requiere un par de tubos con nombre para la comunicación bidireccional. Los sockets de dominio Unix requieren un poco más de sobrecarga para la configuración (creación de socket, inicialización y conexión), pero son más flexibles y pueden ofrecer un mejor rendimiento (mayor rendimiento).

Es posible que deba ejecutar algunos puntos de referencia para su aplicación/entorno específico para determinar qué funcionará mejor para usted. Según la descripción proporcionada, parece que los sockets de dominio Unix pueden ser los más adecuados.

---

Beej's Guide to Unix IPC es bueno para comenzar a utilizar Linux/Unix IPC.

Answer 4

Si el rendimiento realmente se convierte en un problema, puede usar la memoria compartida, pero es mucho más complicado que los otros métodos. Necesitará un mecanismo de señalización para indicar que los datos están listos (semáforo, etc.) y bloqueos para evitar acceso simultáneo a las estructuras mientras se modifican.

Lo bueno es que puede transferir una gran cantidad de datos sin tener que copiarlos en la memoria, lo que definitivamente mejorará el rendimiento en algunos casos.

Quizás haya bibliotecas utilizables que proporcionan primitivas de nivel superior a través de la memoria compartida.

La memoria compartida generalmente se obtiene mmaping el mismo archivo usando MAP_SHARED (que puede estar en un tmpfs si no desea que persista); muchas aplicaciones también usan la memoria compartida System V (en mi humilde opinión por razones históricas estúpidas, es una interfaz mucho menos agradable para la misma cosa)

Answer 5

No puedo creer que nadie haya mencionado dbus.

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

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

podría ser un poco más de la parte superior si su aplicación es de arquitectura sencilla, en cuyo caso - en un entorno integrado controlado donde el rendimiento es crucial - no se puede mejorar la memoria compartida.

Answer 6

Al escribir estas líneas (noviembre de 2014), Kdbus y Binder han abandonado la rama de etapas del kernel de Linux. No hay garantía en este punto de que lo haga, pero la perspectiva es algo positiva para ambos. Binder es un mecanismo liviano de IPC en Android, Kdbus es un mecanismo de IPC tipo dbus en el núcleo que reduce el cambio de contexto, lo que acelera enormemente la mensajería.

También existe la "Comunicación transparente entre procesos" o TIPC, que es robusta, útil para clustering y configuraciones de múltiples nodos; http://tipc.sourceforge.net/