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.