Quelle technique Linux IPC utiliser?
Nous sommes encore dans la phase de conception de notre projet mais nous pensons avoir trois processus distincts sur un noyau Linux embarqué. L'un des processus doit être un module de communication qui gère toutes les communications vers et depuis l'appareil via divers supports.
Les deux autres processus devront pouvoir envoyer/recevoir des messages via le processus de communication. J'essaie d'évaluer les techniques IPC fournies par Linux; le message que les autres processus enverront varieront en taille, des journaux de débogage aux médias en streaming à un débit de ~ 5 Mbit. De plus, les médias pourrait être diffusé en continu simultanément.
Quelle technique IPC technique suggéreriez-vous pour cette application? http://en.wikipedia.org/wiki/Inter-process_communication
Le processeur tourne autour de 400-500 Mhz si cela change quoi que ce soit. N'a pas besoin d'être multiplateforme, Linux seul est très bien. L'implémentation en C ou C++ est requise.
Je choisirais les sockets de domaine Unix: moins de surcharge que les sockets IP (c'est-à-dire pas de communications inter-machines) mais la même commodité sinon.
Lors de la sélection de votre IPC, vous devez tenir compte des causes des différences de performances, notamment les tailles de tampon de transfert, les mécanismes de transfert de données, les schémas d'allocation de mémoire, les implémentations de mécanisme de verrouillage et même la complexité du code.
Parmi les mécanismes IPC mécanismes disponibles, le choix des performances se résume souvent à sockets de domaine Unix ou canaux nommés (FIFO) . J'ai lu un article sur Analyse des performances de divers mécanismes de communication inter-processus qui indique que les sockets de domaine Unix pour IPC peut fournir les meilleures performances. J'ai vu des résultats contradictoires ailleurs qui indiquent que les tuyaux peuvent être meilleurs.
Lors de l'envoi de petites quantités de données, je préfère les canaux nommés (FIFO) pour leur simplicité. Cela nécessite une paire de canaux nommés pour la communication bidirectionnelle. Les sockets de domaine Unix prennent un peu plus de temps à configurer (création, initialisation et connexion de socket), mais sont plus flexibles et peuvent offrir de meilleures performances (débit plus élevé).
Vous devrez peut-être exécuter des tests de performance pour votre application/environnement spécifique afin de déterminer ce qui fonctionnera le mieux pour vous. D'après la description fournie, il semble que les sockets de domaine Unix soient les mieux adaptés.
Beej's Guide to Unix IPC est bon pour commencer avec Linux/Unix IPC.
Je ne peux pas croire que personne n'ait mentionné dbus.
http://www.freedesktop.org/wiki/Software/dbus
http://en.wikipedia.org/wiki/D-Bus
Peut-être un peu trop si votre application est simple sur le plan architectural, auquel cas - dans un environnement intégré contrôlé où les performances sont cruciales - vous ne pouvez pas battre la mémoire partagée.
Si les performances deviennent vraiment un problème, vous pouvez utiliser la mémoire partagée - mais c'est beaucoup plus compliqué que les autres méthodes - vous aurez besoin d'un mécanisme de signalisation pour signaler que les données sont prêtes (sémaphore, etc.) ainsi que des verrous pour empêcher l'accès simultané aux structures pendant leur modification.
L'avantage est que vous pouvez transférer beaucoup de données sans avoir à les copier en mémoire, ce qui améliorera certainement les performances dans certains cas.
Il existe peut-être des bibliothèques utilisables qui fournissent des primitives de niveau supérieur via la mémoire partagée.
La mémoire partagée est généralement obtenue en mmappant le même fichier en utilisant MAP_SHARED (qui peut être sur un tmpfs si vous ne voulez pas qu'il persiste); beaucoup d'applications utilisent également la mémoire partagée System V (à mon humble avis pour des raisons historiques stupides; c'est une interface beaucoup moins agréable pour la même chose)
Au moment d'écrire ces lignes (novembre 2014), Kdbus et Binder ont quitté la branche intermédiaire du noyau Linux. Il n'y a aucune garantie à ce stade que l'un ou l'autre réussira, mais les perspectives sont quelque peu positives pour les deux. Binder est un mécanisme léger IPC dans Android, Kdbus est un mécanisme semblable à dbus IPC dans le noyau, ce qui réduit le changement de contexte, accélérant ainsi considérablement la messagerie).
Il existe également la "communication inter-processus transparente" ou TIPC, qui est robuste, utile pour le clustering et les configurations multi-nœuds; http://tipc.sourceforge.net/
Les sockets de domaine Unix répondront à la plupart de vos besoins en IPC. Vous n'avez pas vraiment besoin d'un processus de communication dédié dans ce cas puisque le noyau fournit cette fonction IPC. Aussi , regardez les files d'attente de messages POSIX qui, à mon avis, est l'une des plus sous-utilisées IPC sous Linux mais est très pratique dans de nombreux cas où des communications n: 1 sont nécessaires.