Partage de données localement (comme avec les sockets) entre plusieurs programmes en C ++

Mon objective est d’ envoyer / partager des données entre plusieurs programmes . Ce sont les options auxquelles j’ai pensé:

  • Je pourrais utiliser un fichier , mais je préfère utiliser ma RAM car elle est généralement plus rapide .
  • Je pourrais utiliser un socket , mais cela nécessiterait beaucoup d’informations sur les adresses, ce qui n’est pas nécessaire pour les applications locales. Et les ports aussi.
  • Je pourrais demander aux autres un moyen efficace de le faire.

J’ai choisi le dernier

Alors, quel serait un moyen efficace d’envoyer des données d’un programme à un autre? Il peut utiliser un tampon , par exemple, et y écrire des octets et attendre que le récepteur marque le premier octet comme “lu” (essentiellement tout ce qui n’est pas écrit) , puis réécrit, mais placerais-je le tampon et Comment pourrais-je le rendre accessible pour les deux programmes? Ou peut-être que quelque chose d’autre pourrait fonctionner aussi?

J’utilise linux.

Qu’en est-il des fifos et des pipes? Si vous êtes sur un environnement Linux, c’est le moyen d’autoriser 2 programmes à partager des données.

L’IPC le plus rapide pour les processus exécutés sur le même hôte est une mémoire partagée.

En bref, plusieurs processus peuvent accéder au même segment de mémoire.

Voir ce tutoriel .

Vous voudrez peut-être jeter un oeil à Boost.Interprocess

Boost.Interprocess simplifie l’utilisation des mécanismes communs de communication et de synchronisation interprocessus et en offre un large éventail:

  • La memoire partagée.

  • Fichiers mappés en mémoire.

  • Sémaphores, mutex, variables de condition et types de mutex pouvant être mis à niveau pour les placer dans des fichiers mappés en mémoire partagée et en mémoire.

  • Versions nommées de ces objects de synchronisation, similaires à l’API UNIX / Windows sem_open / CreateSemaphore.

  • Verrouillage de fichier.

  • Pointeurs relatifs.

  • Files d’attente de messages

Pour répondre à tes questions:

L’utilisation d’un fichier n’est probablement pas la meilleure solution, et les fichiers ne sont généralement pas utilisés pour transmettre des informations de processus interne. Rappelez-vous que le système d’exploitation doit ouvrir, lire, écrire, fermer les. Ils sont cependant utilisés pour le locking ( http://en.wikipedia.org/wiki/File_locking ).

Les performances les plus élevées que vous obtenez avec pipestream ( http://linux.die.net/man/3/popen ), mais sous Linux, il est difficile d’avoir raison. Vous devez redirect stdin, stdout et stderr. Cela doit être fait pour chaque processus interne. Donc, ça va bien fonctionner pour deux applications, mais allez au-delà et ça devient très poilu.

Ma solution préférée, utilisez socketpairs ( http://pubs.opengroup.org/onlinepubs/009604499/functions/socketpair.html ). Celles-ci sont très robustes et faciles à configurer. Mais si vous utilisez plusieurs applications, vous devez préparer une sorte de pool pour accéder aux applications.

Sous Linux, lors de l’utilisation de fichiers, ils sont très souvent en cache, vous ne lirez donc pas souvent le disque, et vous pourriez utiliser un système de fichiers “RAM” comme tmpfs (en fait, tmpfs utilise la mémoire virtuelle, donc les fichiers sont conservés dans la mémoire vive la plupart du temps).

Le problème principal rest la synchronisation .

Utiliser des sockets (qui peuvent être, si tous les processus sont sur la même machine, les sockets AF_UNIX plus rapides que ceux de TCP / IP) ont l’avantage de rendre notre code facilement transférable aux environnements où vous préférez exécuter plusieurs processus sur plusieurs machines.

Et vous pouvez également utiliser un framework existant pour une exécution parallèle, comme par exemple MPI , Corba , etc., etc.

Vous devriez avoir une idée grossière de la bande passante et de la latence attendues de votre application. (Ce n’est pas la même chose si vous devez partager des dizaines de mégaoctets chaque milliseconde, ou des centaines de kilo-octets tous les dixièmes de secondes).

Je suggère d’en apprendre davantage sur les techniques de sérialisation , les formats et les bibliothèques comme XDR, ASN1, JSON, YAML, s11n , jsoncpp, etc.

Et l’envoi ou le partage de données n’est pas la même. Lorsque vous envoyez (et recevez) des données, vous pensez en termes de transmission de messages. Lorsque vous partagez des données, vous pensez en termes de mémoire partagée. Le style de programmation est très différent.

La mémoire partagée est la meilleure pour partager les données entre les processus. Mais il a besoin de beaucoup de synchronisation et si plus de 2 processus partagent les données, alors la synchronisation est comme un cyclope. (Oeil unique – mémoire partagée unique).

Mais si vous utilisez des sockets (sockets multicast), l’implémentation sera peu difficile, mais l’évolutivité et la maintenabilité sont très faciles. Vous n’avez pas à vous soucier du nombre d’applications qui attendent les données, vous pouvez simplement les multidiffuser et elles vont écouter les données et les processus. Pas besoin d’attendre le sémaphore (technique de synchronisation de la mémoire partagée) pour lire les données.

La lecture de l’heure des données peut donc être réduite.
Mémoire partagée – Attendez le sémaphore, lisez les données et traitez les données.
Sockets – Recevoir les données, traiter les données.

La performance, l’évolutivité et la maintenabilité seront des avantages supplémentaires avec les sockets.

Cordialement,
SSuman185