PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : kommunikation zwischen (QT)Programmen



TheDodger
18-02-2002, 14:47
einer muß noch :) ...

achtung betrifft in allen Fällen QT3!

Also ich habe da ein Problem, mit welchem ich vom logischen Standpunkt nicht klar komme ...

Ich habe eine lib erstellt, die mir sämtliche Datenbankfunktionen zur Verfügung stellt.
Programme, die gegen die lib gelinkt sind, haben so die möglichkeit locker auf (irgendeine) SQL-DB zu conecten.

Jetzt soll eine 2. oder 3. (oder n) Applikationen (auch gleichzeitig) laufen.

Wenn ich die 1. App starte, erscheint ein Login-Widget, mit dem ich mich an der DB anmelden kann.
Bei der 2. (3. oder ...) App soll dieses Widget nicht mehr erscheinen, weil ich ja schon angemeldet bin ...
Wenn ich App 1 schließe, und wieder öffne das gleiche.

(Ich hoffe, ich verwirr euch nicht zu sehr ;) )

Eine Art Prozesskommunikation unter QT habe ich nicht gefunden ... leider.

Eine Möglichkeit wäre es, ein tmp.Datei anzulegen, oder Einträge in der DB vorzunehmen, doch wenn ein Programm abstützt, sind die Daten noch vorhanden und somit gäbe es weitere Probleme ...

Und damit es nicht ganz leicht wird ... das ganze soll sowohl unter Linux, als auch unter Windows funktionieren.

Hat jemand eine Idee, oder Denkanstoß für mich?

anda_skoa
26-02-2002, 15:41
Hi Dodger!

Eine Idee wäre ein Server/Client System.

Unter Unix ließe sich sowas fein mit Unix Domain sockets machen, aber unetr Windows wirds die nicht geben.

Mit TCP gehts natürlich auch, der Server sollte dann aber nur auf 127.0.0.1 binden, damit man ihn von außerhalb des Rechners nicht connecten kann.

Der Server wartet dann auf Cleints. Wenn ein Cleint connected, sieht der Server nach, ob schon ein anderer Cleint läuft.
Wenn ja, bekommt der neue Client die Zugangsdaten, wenn nein, dann muß der Cleint sie vom Benutzer erfragen und an den Server senden.

Man kann dann sowas wie Referenzcounting machen, also wenn der letzte Client diconnected, dann gilt für den Server wieder der Anfangszustand.

Der Server muß während er läuft nur hin und wieder die Verbindungen prüfen, damit er erkennen kann, wenn ein cleint abheschmiert ist.
So wie ein Ping praktisch.

Ciao,
_

TheDodger
26-02-2002, 17:30
Haben wir auch schon dran gedacht ... Problemfall wäre in hier der Server, der ja praktisch autm. gestartet werden muß und im Hintergrund laufen sollte.

Was passiert, wenn der abstürtzt ...
Im Moment zuviel Unklarheiten. sobald sich an der 'Front' was tut, schreib ich's hier rein :)

anda_skoa
26-02-2002, 17:50
:)

Das mit dem Starten ist mir auch aufgefallen.
Der Server muß ja ein eigener Prozess werden, also kein Child eines Clients.

Unter Unix ginge das wie das die Daemons machen.
Dort returned der aufgerufen Prozess ja, nachdem er den eigentlichen Daemon geforkt hat.

Wenn man etwas equivalentes unter Windows auch machen kann, dann kann man ja einen solchen Starter in eine Abstrakten Klasse deklarieren und dann zwei Subclassen machen, wo bei dann abhängig von der Plattform die jeweilige instanziiert wird.

Das mit dem abgestürtzen Server ist dann weniger schlimm.
Wenn beim Clientstart der Connect auf 127.0.0.1:xyz failed, muß er gestarte werden.

Wenn der Server abstürzt, dann ist er für den nächsten startenden Client nicht erreichbar un der starter ihn dann.

Außerdem ist es sehr unwahrscheinlich, dass der Server abstürzt, weil er ja fast nichts tut, außer auf Connections zu warten und dann ein simples Protokoll zu fahren :p

Ciao,
_

TheDodger
18-03-2002, 10:34
unter Windows (jedenfalls mit dem M$ compiler) kann man wohl shared Memory Segmente verwalten.
Im Moment haben wir das so gelöst, obwohl mir das ehrlich nicht gefällt ... jetzt muß ich unter Windows weiter programmieren :(

anda_skoa
18-03-2002, 10:52
Shared memory sollte unter Linux gehen.
man shmget

Ciao,
_