IPC multiplateforme

Question

Je recherche des suggestions sur les mécanismes IPC possibles qui sont :

• Plateforme multiplateforme (Win32 et Linux au moins)
• Simple à mettre en œuvre dans C++ aussi bien que langages de script les plus courants (Perl, Ruby, Python, etc.).
• Enfin, simple à utiliser d'un point de vue programmation !

Quelles sont mes options ?Je programme sous Linux, mais j'aimerais que ce que j'écris soit portable sur d'autres systèmes d'exploitation à l'avenir.J'ai pensé à utiliser des sockets, des canaux nommés ou quelque chose comme DBus.

Answer 1

En termes de vitesse, le meilleur mécanisme IPC multiplateforme sera celui des tuyaux.Cela suppose cependant que vous souhaitiez un IPC multiplateforme sur la même machine.Si vous souhaitez pouvoir parler à des processus sur des machines distantes, vous souhaiterez plutôt utiliser des sockets.Heureusement, si vous parlez au moins de TCP, les sockets et les canaux se comportent à peu près de la même manière.Bien que les API permettant de les configurer et de les connecter soient différentes, elles agissent toutes deux simplement comme des flux de données.

Le plus difficile, cependant, n’est pas le canal de communication, mais les messages que vous y faites passer.Vous voulez vraiment regarder quelque chose qui effectuera la vérification et l'analyse pour vous.Je recommande de regarder Google Tampons de protocole.En gros, vous créez un fichier de spécifications qui décrit l'objet que vous souhaitez transmettre entre les processus, et il existe un compilateur qui génère du code dans un certain nombre de langages différents pour lire et écrire des objets qui correspondent à la spécification.C'est beaucoup plus facile (et moins sujet aux bogues) que d'essayer de proposer un protocole de messagerie et de l'analyser vous-même.

Answer 2

Pour C++, consultez Augmenter l'IPC.
Vous pouvez probablement également créer ou trouver des liaisons pour les langages de script.

Sinon, s'il est vraiment important de pouvoir interagir avec des langages de script, le mieux est simplement d'utiliser des fichiers, des canaux ou des sockets ou même une abstraction de niveau supérieur comme HTTP.

Answer 3

Pourquoi pas D-Bus ?Il s'agit d'un système de transmission de messages très simple qui fonctionne sur presque toutes les plates-formes et est conçu pour être robuste.Il est actuellement pris en charge par presque tous les langages de script.

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

Answer 4

Vous voudrez peut-être essayer YAMI , c'est très simple mais fonctionnel, portable et livré avec une liaison dans quelques langues

Answer 5

Si vous souhaitez un logiciel portable, facile à utiliser, multilingue et LGPLsolution ed, je vous recommanderais ZéroMQ:

• Étonnamment rapide, évolutif presque linéaire et toujours simple.
• Convient aux systèmes/architectures simples et complexes.
• Modèles de communication très puissants disponibles :REP-REP, PUSH-PULL, PUB-SUB, PAIRE-PAIRE.
• Vous pouvez configurer le protocole de transport pour le rendre plus efficace si vous transmettez des messages entre les threads (inproc://), les processus (ipc://) ou des machines ({tcp|pgm|epgm}://), avec une option intelligente permettant de réduire une partie des frais généraux de protocole en cas de connexions en cours d'exécution entre des machines virtuelles VMware (vmci://).

Pour la sérialisation, je suggérerais MessagePack ou des tampons de protocole (que d'autres ont déjà mentionnés), en fonction de vos besoins.

Answer 6

Que diriez-vous L'épargne de Facebook?

Thrift est un framework logiciel pour le développement de services multilingues évolutifs.Il combine une pile logicielle avec un moteur de génération de code pour créer des services qui fonctionnent efficacement et de manière transparente entre C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk et OCaml.

Answer 7

Je pense que vous voudrez quelque chose basé sur les sockets.

Si vous voulez RPC plutôt que simplement IPC, je suggérerais quelque chose comme XML-RPC/SOAP qui fonctionne sur HTTP et peut être utilisé à partir de n'importe quel langage.

Answer 8

YAMI - Encore une autre infrastructure de messagerie est un framework léger de messagerie et de mise en réseau.

Answer 9

Si vous êtes prêt à essayer quelque chose d'un peu différent, voici le GLACE plateforme de ZéroC.Il est open source et est pris en charge sur à peu près tous les systèmes d'exploitation auxquels vous pouvez penser, ainsi que sur la prise en charge des langages C++, C#, Java, Ruby, Python et PHP.Enfin, il est très simple à conduire (les mappages de langues sont adaptés pour s'adapter naturellement à chaque langue).C'est aussi rapide et efficace.Il existe même une version réduite pour les appareils.

Answer 10

Je peux vous suggérer d'utiliser le plibsys Bibliothèque C.C'est très simple, léger et multiplateforme.Publié sous la LGPL.Il offre:

• régions de mémoire partagée nommées à l’échelle du système (implémentations System V, POSIX et Windows) ;
• sémaphores nommés à l'échelle du système pour la synchronisation des accès (implémentations System V, POSIX et Windows) ;
• implémentation de tampon partagé nommée à l'échelle du système basée sur la mémoire partagée et le sémaphore ;
• sockets (TCP, UDP, SCTP) avec prise en charge IPv4 et IPv6 (implémentations UNIX et Windows).

C'est une bibliothèque facile à utiliser avec une assez bonne documentation.Comme il est écrit en C, vous pouvez facilement créer des liaisons à partir de langages de script.

Si vous devez transmettre de grands ensembles de données entre processus (surtout si la vitesse est essentielle), il est préférable d'utiliser la mémoire partagée pour transmettre les données elles-mêmes et les sockets pour informer un processus que les données sont prêtes.Vous pouvez le faire comme suit :

• un processus place les données dans un segment de mémoire partagée et envoie une notification via un socket à un autre processus ;comme une notification est généralement très petite, la surcharge de temps est minime ;
• un autre processus reçoit la notification et lit les données du segment de mémoire partagée ;après cela, il envoie une notification indiquant que les données ont été relues au premier processus afin qu'il puisse fournir plus de données.

Cette approche peut être mise en œuvre de manière multiplateforme.

Answer 11

L'informatique distribuée est généralement complexe et il est conseillé d'utiliser des bibliothèques ou des frameworks existants au lieu de réinventer la roue.Les affiches précédentes ont déjà énuméré quelques-unes de ces bibliothèques et frameworks.En fonction de vos besoins, vous pouvez choisir un framework de très bas niveau (comme les sockets) ou de haut niveau (comme CORBA).Il ne peut pas y avoir de réponse générique « utiliser ceci ».Vous devez vous renseigner sur la programmation distribuée et il vous sera alors beaucoup plus facile de choisir la bonne bibliothèque ou le bon framework pour le travail.

Il existe un framework C++ largement utilisé pour l'informatique distribuée appelé ACE et CORBA ORB TAO (qui est basé sur ACE).Il existe de très bons livres sur ACE http://www.cs.wustl.edu/~schmidt/ACE/ donc tu pourrais y jeter un oeil.Prends soin de toi!

Answer 12

Il n’y a rien de plus simple que d’utiliser des tubes, qui sont pris en charge sur tous les systèmes d’exploitation que je connais et sont accessibles dans presque toutes les langues.

Vérifier ce Didacticiel.

Answer 13

Sockets TCP vers localhost FTW.

Answer 14

Python possède une très bonne bibliothèque IPC :voir https://docs.python.org/2/library/ipc.html

Answer 15

Xojo dispose d'un support IPC multiplateforme intégré avec son Classe IPCSocket.Bien que vous ne puissiez évidemment pas "l'implémenter" dans d'autres langues, vous pouvez l'utiliser dans une application console Xojo et l'appeler depuis d'autres langues, ce qui rend cette option peut-être très simple pour vous.

Answer 16

Les protobufs Google sont une très mauvaise idée car vous voulez un code facile à maintenir et à déboguer.il est trop facile pour les gens d'en abuser et de l'utiliser pour polluer votre code.les fichiers proto sont sympas, mais c'est fondamentalement la même chose qu'un fichier d'en-tête de structure, et le code qu'il génère est complètement de la merde, ce qui vous fait vous demander s'il s'agit vraiment d'un outil d'attaque secret pour saboter des projets logiciels au lieu de les automatiser.Après l’avoir utilisé pendant un certain temps, il est presque impossible de le supprimer de votre code.il est préférable d'utiliser simplement un fichier d'en-tête de structures de format fixe qui sont facilement déboguées.

si vous avez vraiment besoin de compression, passez à distance à un mappage adresse/données des structures de classement...alors les paquets ne sont qu'un ensemble de paires adresse/données...également une structure très facile à automatiser avec vos propres scripts Perl qui produisent du code lisible et déboguable par l'homme