qtforum.de

Hallo,
ich schreibe gerade an meiner Diplomarbeit und habe deswegen ein etwas kniffliges Problem.

Mein Ziel ist es zwei Applikationen (basierend auf Qt, geschrieben in C++) zu bauen die sich gegenseitig über Netzwerk (LAN) signals zuschicken können und damit in der jeweils anderen Applikation den verbundenen slot auslösen.

Die Firma die mir das Thema gestellt hat, hat bereits eine Lösung die auf Sockets basiert, welche aber schwer zu erweitern ist, da bei jedem neuen Signal viel Code per Hand hinzugefügt werden muß. Ihnen schwebt eine Lösung vor, bei der sie mehr oder weniger nur das Interface / die Signatur des Signals angeben müssen und der restliche Netzwerkrelevante Code automatisch generiert wird. Dieses Vorgehen ist vergleichbar mit dem eines IDL Compilers einer Middleware.

Deswegen sollte ich zunächst nach Middleware Lösungen suchen, die direkt mit Signal / Slot umgehen können. Mein erster Gedanke war CORBA, aber mittlerweile weiß ich das CORBA nicht direkt mit Signal/Slot arbeiten kann.

Mein nächster Ansatz war das Desktop COmmunication Protocol (DCOP) welches von KDE entwickelt wurde. KDE hat früher CORBA zur Interprozess kommunikation eingesetzt und dieses später durch DCOP ersetzt.
Mit DCOP kann man jede Applikation zu einer DCOP-Client-Applikation machen, welche sich am DCOP Server anmelden kann und dann mit anderen DCOP-Client-Applikationen kommunizieren kann. Dies funktioniert auch mit der Signal/Slot Semantik. Es sind zwar nicht die Original Qt Signal/Slots aber sie sind sehr stark daran angelehnt. Ausserdem verfügt DCOP über einen IDL-Compiler, der alles weitgehend automatisiert. Leider ist es mir nicht gelungen eine DCOP-Client-Applikation an einem DCOP-Server anzumelden der auf einem anderen (über LAN verbundenen) Rechner läuft.
Zwar wird DCOP sehr oft als RPC/IPC Protocol bezeichnet und kann angeblich auch TCP/IP Sockets nutzen, aber die Kommunikation über Netzwerk scheint nicht vorgesehen zu sein.

Falls jemand weiß wie man mit DCOP übers Netzwerk kommuniziert wäre ich dankbar wenn er verrät wie (selbst wenn es nur mit irgend einer Form von Bridge funktioniert).
Im Zweifel würde es mir auch helfen, wenn mir jemand glaubhaft versichern kann, das Netzwerkkommunikation über DCOP nicht funktioniert, damit ich den Ansatz endgültig verwerfen kann.

Kennt jemand zufällig irgend eine Middleware (oder ähnliches), welche mit Signal/Slot direkt umgehen kann?

Kann sich jemand irgend eine andere Art von Lösung für mein Problem vorstellen?

Vielen Dank im Voraus!

Gruß,

Alex

Hallo Alex,

ich bin nicht wirklich firm mit DCOP, aber nach dem was ich gerade gelesen habe ist eine Kommunikation übers Netz möglich, solange beide Applikationen am selben DCOP-Server hängen.

Soweit ich das verstanden habe muss sich also eins der beiden Programme am DCOP-Server des anderen anmelden.

Wie das geht steht hier:
http://developer.kde.org/documentation/ ... tml#sec2.4

aber soweit warst du warscheinlich auch schon.

Ich habe zwar in dem Bereich noch nichts gemacht, aber interessieren tut es mich dann auch, falls Du es zum laufen gebracht hast.


gruß,

needle

Vielleicht hilft dir auch das hier weiter:

XmlRpc Daemon
http://developer.kde.org/documentation/ ... mlrpc.html

interessant wäre vielleicht auch das QT-Beispiel remotecontrol

hier werden komplette Objekte per Socket-Verbindung übertragen.

als Signal Slot Ersatz vielleicht nur bedingt geeignet, aber anschauen lohnt bestimmt.

needle

Hallo needle und Spring-Daniel,
daß sich beide DCOP-Clients am selben DCOP-Server anmelden müssen wußte ich schon. Die Beschreibung, auf die Du gelinkt hast kannte ich auch schon, sie gilt aber soweit ich das sehe nur für Inter-user Kommunikation auf einem Rechner. Also wenn z.B. ein Client als Hintergrund-prozess unter root läuft und ein anderer user mit seinem Client mit ihm kommunizieren will (oder so ähnlich). Das mag ja funktionieren, hat aber leider nichts mit Netzwerkkommunikation zu tun. Die Clients melden sich nämlich standardmäßig erst mal auf ihrem lokalen DCOP-Server an, was mir ja nix bringt, da sie ja beide am selben hängen müssen. Habe auch schon mit der setServerAdress( adresse) - Methode der DCOP Client Klasse rumexperimentiert. Allerdings steht nirgends in welchem Format die Adresse übergeben werden muß. Ich nehme an als Adressinformationen dienen die Daten aus der Datei ".DCOPServer".
Da steht beispielsweise:

local/psu3:/tmp/.ICE-unix/dcop6730-1099920411
6730

habe sowohl:

client->setServerAddress("local/psu3:/tmp/.ICE-unix/dcop6730-1099528030:6730");

als auch:

client->setServerAddress("psu3:/tmp/.ICE-unix/dcop6730-1099528030:6730");

probiert. Funktioniert beides nicht. Nicht mal wenn ich auf dem Rechner arbeite auf dem dieser Server läuft?!? Die Angabe der IP Adresse bringt auch nix, die kann er nicht parsen. Weiß also nicht in welchem Format er die Adresse schluckt.

Das mit dem (K)XmlRPC hab ich auch schon gesehen, bin mir aber nicht sicher ob es mir weiterhilft. Einerseits wurde dessen Entwicklung von KDE wieder eingestellt und in aktuellen KDE Versionen ist er auch gar nicht mehr enthalten. Ausserdem kann man sich damit - soweit ich es verstanden habe - nur eine Art XML-Client schreiben mit dem man einen DCOP-Client auf einem anderen Rechner fernsteuern kann. Man kann dabei aber glaub ich nur Funktionen aufrufen und kein Signal schicken, welches dann einen verbundenen Slot ausführt. Korrigiert mich bitte, falls ich hier einer Fehleinschätzung unterliege.

Trotzdem vielen Dank.