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.
[gelöst] QSharedMemory und verschiedene Nutzer
-
BartSimpson
- Beiträge: 1379
- Registriert: 6. November 2004 12:03
- Kontaktdaten:
[gelöst] QSharedMemory und verschiedene Nutzer
Zuletzt geändert von BartSimpson am 19. November 2009 07:47, insgesamt 1-mal geändert.
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
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 ...
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
So ungewöhnlich waer die Loesung auch wieder nedUnd bevor ich es per UDP ...
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 ...
-
BartSimpson
- Beiträge: 1379
- Registriert: 6. November 2004 12:03
- Kontaktdaten:
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 ...
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 ...
-
BartSimpson
- Beiträge: 1379
- Registriert: 6. November 2004 12:03
- Kontaktdaten:
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.
-
BartSimpson
- Beiträge: 1379
- Registriert: 6. November 2004 12:03
- Kontaktdaten: