Introduction

Dans les programmes informatiques, les IPCs sont partout et de types très divers.

Pour rappel, il s’agit là de diverses technologies qui permettent à plusieurs processus de communiquer entre deux (comprendre : se partager des données).

Il y a, à mon sens 2 niveaux d’IPCs :

• Les IPCs “bas niveau”, implémenté par le kernel :
  • implémente des fonctionnalités simples.
  • peu abstrait (besoin de définir la taille de l’espace alloué dans le cas d’un segment de mémoire partagé par exemple).
  • Sous linux, on à notamment :
    • Tube(pipe)
    • Fichier
    • Socket (utilisé pour le réseau notamment)
    • Signaux (plutôt utilisé pour agir sur l’état du service, sens standardisé)
    • Segment de mémoire partagée
    • des mécanismes de synchronisations : ex : les semaphores.
• Les IPCs “haut niveau” :
  • Basé sur les IPC bas niveau (très souvent les sockets).
  • Plus abstraits.
  • Ajoute de diverses garanties selon les technologies, par exemple :
    • bonne récéption des données.
    • validation d’un format des données.
    • récéption synchrone (RPC) ou asynchrone (mq)
    • diverse paradigme de communication (Stream, PubSub), etc.
    • Logique unidirectionnelle, bidirectionnelle ou encore vers n récepteurs.

Si l’on comprend les IPC “haut-niveau”, les technologies de communications entre processus sont très nombreuses et il n’est pas toujours si simple de savoir quoi utiliser, ce qui abouti dans de nombreux cas à utiliser les technologies connu plutôt qu’une éventuelle meilleure technologie pour le cas d’usage.

Bref, j’avais du temps à perdre et j’ai donc réalisé un petit programme nommé Universal Ping, ou j’ai testé plus des dizaines d’IPC avec ces contraintes :

• Langage Python
• Communication simple type “RPC”:
  • Appel “Ping” avec variable de nombre “n”
  • Retour “n” fois “Pong…”

J’en ai profité pour essayer de clarifier dans ma tête tout cela. Voici donc ma façon, sous forme d’arbres de décisions de présenter la diversité des ces IPCs :

Quel IPC Choisir ?

J’ai organisé les IPCs autour d’un point qui me semble assez important : L’IPC fournit-elle une API ? Et si oui, est-elle prévu pour être utilisé publiquement (comprendre par des programmes totalement extérieurs sans difficultés).

J’ai donc séparé les IPC en trois catégories :

1. Les IPCs conçu pour fournir une API “publique” explicite.
2. Les IPCs conçu pour fournir une API “privée” explicite (plutôt conçu pour une application en plusieurs parties).
3. Les IPCs sans support intégré de mécanisme d’API.

Note : Il s’agit là d’une organisation subjective. Bien évidemment, il est toujours tout à fait possible d’utilisé une IPC sans mécanisme d’API et d’ajouter une documentation d’une API et/ou un sur-couche logicielle qui gèrerait l’API, mais cela sera moins “standard” qu’une technologie qui est conçue dans ce but.

API Publique

Si je veux concevoir un logiciel sur lequel d’autres logiciels peuvent se brancher, c’est vers ces solutions que je me tournerais :

API Privée

Si je devais faire un logiciel “en plusieurs parties”, ces solutions sont élégantes :

L’aspect API est particulièrement intéressant si vous voulez travailler à plusieurs sur différente partie sans vous marcher dessus.

Les autres IPCs

Ces technos requièrent une clarification d’API entre les différents processus utilisant la technologie pour être utilisé convenablement. Cependant, elles sont pour beaucoup simple d’accès et n’ont pas forcément les mêmes avantages que les technologies précédentes, je pense en particulier :

• L’aspect stockage des BDD
• L’aspect asynchrone des Messages Queue.

Certaines ont aussi des cas d’usage très défini et sont quasi-imbattable dans ce cadre précis, je pense en particulier à MQTT pour des capteurs. L’absence d’API clarifié n’est pas forcément un gros soucis notamment ll est très facile de regarder le flux avec un outil comme MqttExplorer et que les avantages du protocole surpassent cet inconvénient mineur pour ce cas d’usage.

Mon avis ?

En faisant ce petit test de divers IPC, il y a clairement des technologies que j’apprécie plus que d’autres :

• IPC trop complexe à mon goût (besoin très particulier, gros projet, usage legacy) :

  • IPC bas niveau : Amusant jusqu’au moment ou il faut réimplémenter les fonctionnalité d’un ZMQ.
  • GRPC/Thrift: Je trouve l’intégration dans Python, en particulier de GRPC très lourde.
  • RabbitMQ (et probablement Kafka) : Le code python pour mon petit RPC m’a paru inutilement compliqué.

• Standard de fait :

  • OpenAPI, Rest : Pour tout ce qui est Web.
  • MQTT : Pour les capteurs.
  • D-BUS : Pour la communication avec un démon quelconque dans un Linux Desktop.

• Simple et efficace :

  • varlink: Je pense que c’est l’idéal si vous avez besoin d’une API de communication qui “sort” d’un logiciel dans un conteneur.
  • rpyc: Très facile à prendre en main, parfait pour prototyper un logiciel distribué rapidement.
  • ZMQ : Super simple d’accès là aussi.
  • Redis/Valkey : BDD très versatile, intéressant pour partager des données à faible durée de vie.

👋 Voilà, Voilà, plus qu’à trouver des cas d’usage concrêt pour jouer avec plus de ces technos 😅 !