Service und Interprozesskommunikation

[Union]

Ich will einen Service erstellen, der durch ein zugehöriges Programm (Agent) gesteuert werden soll.
Kommunikation von Dienst <> VCL-Anwendung hat mir da leider auch nicht weitergeholfen. Es soll folgendes implementiert werden:

• Der Service führt zeitgesteuert bestimmte Operationen aus
• Wenn der Service eine Aktion durchführt, soll dies im Agent angezeigt werden (Memo, Listbox)
• Die Aktionen des Service sollen auch durch den Agent manuell angestossen werden können
• Wenn der Service gerade eine Aktion ausführt, soll diese zum gleichen Zeitpunkt nicht vom Agent nochmals gestartet werden können.
• Steuerung über Registry oder Files wie hier jasocul verbietet sich wegen restriktiver Benutzerberechtigungen

Wer hilft?

[Luckie]

Ich würde Pipes oder MMFs benutzen. Da der Link nicht funktionieret, weiß ich nicht, was du dazu schon gefunden hast.

[Union]

Zitat von Luckie:

Ich würde Pipes oder MMFs benutzen. Da der Link nicht funktionieret, weiß ich nicht, was du dazu schon gefunden hast.

Komisch, bei mir funktioniert der Link: www.jasocul.de

Er hat dort eine Service-Anwendung mit einem entsprechenden Frontend erstellt, mit dem eine Steuerung möglich ist. Aber er verwendet für die Kommunikation und Konfiguration eine "Auftragsdatei" und Registry-Einträge. In meinem Fall kann es aber sein, daß der Benutzer, der sich den Status ansieht oder den Service bedient, weder Schreibzugriff auf alle Bereiche der Registry hat, noch Zugriffsrechte auf das Anwendungsverzeichnis des Service.

[Luckie]

Ich meinte den ersten Link: http://www.delphipraxis.net/post329947.htm

[Union]

Zitat von Luckie:

Ich meinte den ersten Link: http://www.delphipraxis.net/post329947.htm

Sorry, der richtige Link ist http://www.delphipraxis.net/internal...ct.php?t=48550

[Luckie]

Was gefällt dir jetzt nicht an Pipes oder MMfs?

[Union]

Zitat von Luckie:

Was gefällt dir jetzt nicht an Pipes oder MMfs?

Bei MMFs gibt es einen herben Aufwand um die Berechtigungen aus dem Systemaccount auf die Useraccounts zu übertragen mit dem TSecurityDescriptor. Da ist ja der Aufbau der Struktur und der Berechtigungen größer als mein ganzes Programm

[NicoDE]

Den Aufwand wirst Du auch mit Events haben (mit eben jenen würde ich das Problem lösen, da keine Daten übertragen werden müssen).
Die Erzeugung eines 'Vollzugriff's-ACLs ist relativ trivial und läßt sich bequem in eine Funktion packen.

ps: nebenbei, bei globalen Synchronisations-Objekten sollte man berücksichtigen, dass der Service unter Umständen auf einem Terminal-Server (oder Windows XP mit 'schneller Benutzerumschaltung') mit mehreren Sessions läuft. Deswegen würde ich von Steurungsdateien und der Registry abraten (oder eine Session-ID in den Objekt-Namen einfügen).

[Union]

Zitat von NicoDE:

Den Aufwand wirst Du auch mit Events haben (mit eben jenen würde ich das Problem lösen, da keine Daten übertragen werden müssen).
Die Erzeugung eines 'Vollzugriff's-ACLs ist relativ trivial und läßt sich bequem in eine Funktion packen.

ps: nebenbei, bei globalen Synchronisations-Objekten sollte man berücksichtigen, dass der Service unter Umständen auf einem Terminal-Server (oder Windows XP mit 'schneller Benutzerumschaltung') mit mehreren Sessions läuft. Deswegen würde ich von Steurungsdateien und der Registry abraten (oder eine Session-ID in den Objekt-Namen einfügen).

Leider müssen doch Daten übertragen werden: Wenn der Service eine Aktion durchführt, soll dies im Agent angezeigt werden (Memo, Listbox). Problematisch wird es allerdings dann, wenn ich will, dass garantiert alle Protokoll-Einträge im Client angezigt werden. Dann muss ich nämlich im Service a) Feststellen ob überhaupt ein Client läuft und b) wenn ja, darauf warten, dass in der Struktur mitgeteilt wird (evtl. durch Löschen des Strings) dass das Abholen erfolgt ist. Ich bräuchte also für diese Nachrichtenübermittlung im optimalen Fall einen eigenen Thread mit eigenem Zeilen-Puffer, damit der Haupt-Service nicht anhält, weil er auf den Client warten muss. Vielleicht ist es besser, wenn ich einen IDTcpServer/Client dafür verwende mit entsprechend konfigurierten Commands. Dann ist das einzige was passieren kann, dass der Cleint beim Start einen Connection-Timeout erhält, wenn der Service nicht gestartet ist.

Und genau, das Teil soll später auf einem W2003 Server laufen, wobei auch Terminal Server für die Fernbedienung oder gelegentliche Kontrolle über ein Admin-Account erfolgen soll.