Plattformübergreifender IPC [geschlossen]

Ich suche nach Vorschlägen für mögliche IPC-Mechanismen, die:

• Plattformübergreifend (mindestens Win32 und Linux)
• Einfach in C ++ zu implementieren sowie in den gängigsten Skriptsprachen (Perl, Ruby, Python usw.).
• Endlich einfach zu bedienen aus programmtechnischer Sicht!

Welche Möglichkeiten habe ich? Ich programmiere unter Linux, möchte aber, dass das, was ich schreibe, in Zukunft auf andere Betriebssysteme portierbar ist. Ich habe darüber nachgedacht, Sockets, Named Pipes oder ähnliches wie DBus zu verwenden.

In Bezug auf die Geschwindigkeit sind Rohre der beste plattformübergreifende IPC-Mechanismus. Dies setzt jedoch voraus, dass Sie einen plattformübergreifenden IPC auf demselben Computer wünschen. Wenn Sie mit Prozessen auf Remotecomputern kommunizieren möchten, sollten Sie stattdessen Sockets verwenden. Glücklicherweise verhalten sich Sockets und Pipes, wenn Sie zumindest über TCP sprechen, ziemlich ähnlich. Während die APIs zum Einrichten und Verbinden unterschiedlich sind, verhalten sich beide nur wie Datenströme.

Der schwierige Teil ist jedoch nicht der Kommunikationskanal, sondern die Nachrichten, die Sie über ihn leiten. Sie möchten sich wirklich etwas ansehen, das für Sie eine Überprüfung und Analyse durchführt. Ich empfehle, sich die Protokollpuffer von Google anzusehen . Grundsätzlich erstellen Sie eine Spezifikationsdatei, die das Objekt beschreibt, das Sie zwischen Prozessen übergeben möchten, und es gibt einen Compiler, der Code in verschiedenen Sprachen zum Lesen und Schreiben von Objekten generiert, die der Spezifikation entsprechen. Es ist viel einfacher (und weniger fehleranfällig) als ein Messaging-Protokoll zu erstellen und selbst zu analysieren.

Informationen zu C ++ finden Sie unter Boost IPC .
Sie können wahrscheinlich auch einige Bindungen für die Skriptsprachen erstellen oder finden.

Wenn es wirklich wichtig ist, mit Skriptsprachen kommunizieren zu können, verwenden Sie am besten einfach Dateien, Pipes oder Sockets oder sogar eine übergeordnete Abstraktion wie HTTP.

Warum nicht D-Bus? Es ist ein sehr einfaches Nachrichtenübermittlungssystem, das auf fast allen Plattformen ausgeführt wird und auf Robustheit ausgelegt ist. Es wird zu diesem Zeitpunkt von so ziemlich jeder Skriptsprache unterstützt.

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

Wenn Sie eine tragbare, benutzerfreundliche, mehrsprachige und LGPL- Lösung suchen , würde ich Ihnen ZeroMQ empfehlen :

• Erstaunlich schnell, fast linear skalierbar und trotzdem einfach.
• Geeignet für einfache und komplexe Systeme / Architekturen.
• Sehr leistungsfähige Kommunikationsmuster verfügbar: REP-REP, PUSH-PULL, PUB-SUB, PAAR-PAAR.
• Sie können das Transportprotokoll so konfigurieren, dass es effizienter ist, wenn Sie Nachrichten zwischen Threads ( inproc://), Prozessen ( ipc://) oder Maschinen ( {tcp|pgm|epgm}://) übergeben. Mit einer intelligenten Option können Sie einen Teil des Protokoll-Overheads sparen, wenn Verbindungen zwischen VMware ausgeführt werden virtuelle Maschinen ( vmci://).

Für die Serialisierung würde ich je nach Bedarf MessagePack- oder Protokollpuffer (die bereits von anderen erwähnt wurden) vorschlagen .

Vielleicht möchten Sie YAMI ausprobieren , es ist sehr einfach, aber funktional, portabel und mit einer Bindung an wenige Sprachen ausgestattet

Wie wäre es mit Facebooks Thrift ?

Thrift ist ein Software-Framework für die skalierbare Entwicklung sprachübergreifender Dienste. Es kombiniert einen Software-Stack mit einer Code-Generierungs-Engine, um Dienste zu erstellen, die effizient und nahtlos zwischen C ++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C #, Kakao, Smalltalk und OCaml arbeiten.

Ich denke, Sie wollen etwas, das auf Steckdosen basiert.

Wenn Sie RPC anstatt nur IPC möchten, würde ich etwas wie XML-RPC / SOAP vorschlagen, das über HTTP ausgeführt wird und in jeder Sprache verwendet werden kann.

YAMI - Eine weitere Messaging-Infrastruktur ist ein leichtes Messaging- und Netzwerk-Framework.

Ich kann Ihnen vorschlagen, die plibsys C-Bibliothek zu verwenden. Es ist sehr einfach, leicht und plattformübergreifend. Veröffentlicht unter der LGPL. Es bietet:

• benannte systemweite gemeinsam genutzte Speicherbereiche (System V-, POSIX- und Windows-Implementierungen);
• benannte systemweite Semaphore für die Zugriffssynchronisation (System V-, POSIX- und Windows-Implementierungen);
• benannte systemweite Implementierung eines gemeinsam genutzten Puffers basierend auf dem gemeinsam genutzten Speicher und dem Semaphor;
• Sockets (TCP, UDP, SCTP) mit IPv4- und IPv6-Unterstützung (UNIX- und Windows-Implementierungen).

Es ist einfach, eine Bibliothek mit einer recht guten Dokumentation zu verwenden. Da es in C geschrieben ist, können Sie problemlos Bindungen aus Skriptsprachen erstellen.

Wenn Sie große Datenmengen zwischen Prozessen übergeben müssen (insbesondere wenn Geschwindigkeit wichtig ist), ist es besser, gemeinsam genutzten Speicher zu verwenden, um die Daten selbst und Sockets zu übergeben, um einen Prozess zu benachrichtigen, dass die Daten bereit sind. Sie können es wie folgt machen:

• Ein Prozess legt die Daten in einem gemeinsam genutzten Speichersegment ab und sendet eine Benachrichtigung über einen Socket an einen anderen Prozess. Da eine Benachrichtigung normalerweise sehr klein ist, ist der Zeitaufwand minimal.
• Ein anderer Prozess empfängt die Benachrichtigung und liest die Daten aus dem gemeinsam genutzten Speichersegment. Danach sendet es eine Benachrichtigung, dass die Daten zum ersten Prozess zurückgelesen wurden, damit mehr Daten eingespeist werden können.

Dieser Ansatz kann plattformübergreifend implementiert werden.

Wenn Sie bereit sind, etwas anderes auszuprobieren, gibt es die ICE- Plattform von ZeroC . Es ist Open Source und wird auf nahezu jedem denkbaren Betriebssystem unterstützt. Außerdem bietet es Sprachunterstützung für C ++, C #, Java, Ruby, Python und PHP. Schließlich ist es sehr einfach zu fahren (die Sprachzuordnungen sind so zugeschnitten, dass sie natürlich in jede Sprache passen). Es ist auch schnell und effizient. Es gibt sogar eine abgespeckte Version für Geräte.

Distributed Computing ist normalerweise komplex und es wird empfohlen, vorhandene Bibliotheken oder Frameworks zu verwenden, anstatt das Rad neu zu erfinden. Das vorherige Poster hat bereits einige dieser Bibliotheken und Frameworks aufgelistet. Abhängig von Ihren Anforderungen können Sie entweder ein sehr niedriges Level (wie Sockets) oder ein High-Level-Framework (wie CORBA) auswählen. Es kann keine generische "benutze diese" Antwort geben. Sie müssen sich über verteilte Programmierung informieren und finden es dann viel einfacher, die richtige Bibliothek oder das richtige Framework für den Job auszuwählen.

Es gibt ein häufig verwendetes C ++ - Framework für verteiltes Rechnen namens ACE und das CORBA ORB TAO (das auf ACE aufbaut). Es gibt sehr gute Bücher über ACE http://www.cs.wustl.edu/~schmidt/ACE/, also schauen Sie mal rein. Pass auf!

Einfacher geht es nicht als mit Pipes, die von jedem mir bekannten Betriebssystem unterstützt werden und auf die in nahezu jeder Sprache zugegriffen werden kann.

Schauen Sie sich dieses Tutorial an.

TCP-Sockets an localhost FTW.

Python hat eine ziemlich gute IPC-Bibliothek: siehe https://docs.python.org/2/library/ipc.html

Xojo verfügt mit seiner IPCSocket-Klasse über eine integrierte plattformübergreifende IPC-Unterstützung . Obwohl Sie es offensichtlich nicht in anderen Sprachen "implementieren" konnten, können Sie es in einer Xojo-Konsolen-App verwenden und aus anderen Sprachen aufrufen, was diese Option für Sie möglicherweise sehr einfach macht.

In der heutigen Zeit gibt es eine sehr einfache, C ++ 1x-kompatible, gut dokumentierte, Linux- und Windows-kompatible Open-Source-Bibliothek "CommonAPI": CommonAPI C ++ .

Das zugrunde liegende IPC-System ist D-Bus (libdbus) oder SomeIP, wenn Sie dies wünschen. Anwendungsschnittstellen werden mit einer einfachen und auf diese Franca IDL-Sprache zugeschnittenen Sprache angegeben.