qtforum.de

Hallo,
ich suche eine IPC Lösung die über Benutzergrenzen hinweg funktioniert.
Bisher mache ich das mit D-Bus. Nur ist der Windows Port irgenwie stehen geblieben. Also muss was anderes her. Und bevor ich es per UDP mache die kurze Frage ob sich QSharedMemory für folgendes Szenario eignet.

Ein Deamon Prozess der unter dem Nutzer X läuft tauscht mit Prozessen die unter verschiedensten Nutzern laufen Daten aus. Die Daten werden von beiden Seiten geschrieben. Geht dies mit QSharedMemory? Da ich ich in der Doku die mögliche Fehlermeldung QSharedMemory::PermissionDenied gefunden habe.

Unter welchen BS proggst du ? Soll das ganze plattformunabhaengig werden ???

zu SHM:
- Shared memory iss die performanteste Art der IPC
- kann lese und schreibeoperationen mehreren clients bieten
- geht auch benutzeruebergreifend
- bei gleichzeitigigen konkurrierenden zugriffen kommt es ohne explizieten schutzmechanismen, aka prozessglobale Mutexe /Semophoren / Events ned aus. Nen Mutex auf nem SHM zu konstruieren iss ned immer möglich (zumindest mein kentnissstand) da ein zugriff auf nen SHM nie ne atomare operation werden kann, und ned jedes BS dazu hilfsfunktiuonen bietet (zumindest mein kentnissstand). Du bist bei sowas auf andere globale IPC mechanismen zusaetzlich angewiesen.

ergo, SHM laesst sich irgendwie eklig programmieren.

Mit QSHaredMemory kenn ich mich gar ned aus. Ich weiss nur, das man wenn man nen SHM erstellen laesst, die zugriffsrechte mit einstellen kann. Ich denk mal das dein versuch den SHM einfach einzurichten da einfach keine berechtigung fuer andere User gesetzt hat. Ob man das mit QSHaredMemory kann und wie man draufkommt, keine Ahnung wie gesagt.

Prinzipiell besser zu haendlen, find ich zumindest, sind pipes. Da brauchst dich um das schuetzen ned zu kuemmern.
du kannst fuer ne bidirektionale kommunikation auch hin und rueckpipes aufbauen, genau so wie du pipes bauen kannst, in die der server schreibt, und alle clients das selbe draus lesen. Villeicht waer das eher was fuer dich. Leider qibts, glaub ich, keine Hilfsklasse in der Qt fuer Pipes. Wahrscheinlich weil die unterstuetzung von pipes unter windows aehm ziemlich rudimentaer ist.

Shared Memory wuerd ich nur nehmen, wenn wirklich sehr wild auf deinen Speicher herumspringen musst .... also mal von der stelle lesen, dann von da, dann von dort.
Hasst du ne mehr event getriggerte anwendung, also tauschst Daten durch nen Datenstrom, also schreibst und liest nur sequentiell, dann wuerd ich mir was komfortableres suchen

Und bevor ich es per UDP ...

So ungewöhnlich waer die Loesung auch wieder ned
Du weisst scho, das der TCP/IP stack meistens so intelligent ist, und lokale verbindungen ned zum Netzwerkkartentreiber schickt, sondern daraus IPC, also sowas wie ne, oder sogar ne richtige, pipe draus macht.

Unter linux kannst fuer pipes sogar die Socket schnittstellen nutzen, wenn statt AF_INET was anderes nimmst, musst in socket.h mal schauen was es da gibt

Ciao ...

Das ganze soll unter Linux und Windows laufen.
viel Daten werden nicht ausgetauscht.

Ja beschreib mal bissi mehr ....

was fuer daten sind das so .... ? wieviel latenz darf die kommunication haben ? Was bedeutet "nicht viel" ...

Sind die Prozesse miteinander verwand, es wird nur ein Parent gestartet, und der startet per fork /createProcess die anderen ? Aber glaub eher ned ... also wahrscheinlich nicht verwandt.

Ist die kommunikation ueber rechner hinweg für spaeter vielleicht vorgesehen, oder ist es prinzipiell festgelegt, das das zeugs immer auf einer maschine rennt ?

Das wahrscheinlich unkomplizierteste waere ne rudimentaere Implementation ueber nen temporaeres File.
Das kann man spaeter immer noch durch andere IO routinen austauschen.

Versuch erst mal nen grundlegendes Interface nur fuer deine Kommunikation zu erzeugen, an hand dessen sieht man eigentlich ganz gut, was gehen muss und was ned.
auch wenn das nur nen read und nen write hat

Ciao ...

Die Latenz ist eigentlich egal. Das sind nur kurze XML Brocken die in beide Richtungen ausgetauscht werden. Nee die Prozesse sind nicht verwandt sondern völlig eigenständig. Es wird zwar über Rechnergrenzen was ausgetauscht(was ebenfalls ein XML Brocken ist), aber nur von einer der beiden Komponenten via UDP.

also wenns ned auf performance und latenz ankommt, dann wuerd ich ned viel muehe verschwenden, und das zeugs auch ueber den TCP/IP stack, allerdings dann an den localhost schicken ....

falls du wie gesagt ganz heftige abneigung dagegen hasst, dann nimm ne named pipe ...

Ciao ...

Abneigung habe ich gegen nichts.
Ich wollte nur wissen ob jemand noch eine andere Idee hat, die eventuell sinnvoller ist. Also zurück ans Reißbrett und das ganze per UDP.
Sicher nur auf localhost.)
Danke für euren Ideen.