Ich habe einen Service und eine Exe. Der Service läuft mit Admin rechten, die Exe nicht. Bei bestimmten Events wird die Exe vom Service informiert. Es ist derzeit so implementiert dass die Exe einen Indy TCP Server hat, der Service einen Indy TCP client. Der Service loggt sich ein und kann so die Daten (immer ein Byte pro Stunde) übertragen.

Das funktioniert zwar, aber in der (größeren) Firma wo es eingesetzt kommt es immer wieder zu Problemen weil der Serverport geblockt wird. (Sehr chaotische Software-Zustände zwischen verschiedenen Abteilungen).

Gibt es vielleicht eine einfachere Methode um ein Byte an Daten von einem Service an eine Exe weiterzuleiten?

SendMessage() oder PostMessage() kommt ja nicht in Frage, weil der Service und die Exe in einer jeweils anderen Windows Station laufen.

Also habe ich es mit Named Pipes versucht. Es klappte zuerst. Jedoch dann bekam ich Feedback dass ich einer der Abteilungen meine Exe mit sehr niedrigen Systemrechten läuft (die gleichen wie der Internet Explorer) und dadurch keine Pipe Verbindung zu stande kommt.

Hat jemand von euch eine andere Idee?

Dreh das Szenario einfach um.

Die Service-Anwendung hat den TCP Server und die Client-Anwendung den TCP Client.

Die Client-Anwendung fragt nun (am sinnvollsten in einem Thread) in regelmässigen Abständen den Server und der gibt dann die Information heraus.

Schon haben sich deine Probleme erledigt.

wenn die Admin nicht mitspielen wird als kleinste gemeinsamer Nenner ein Austauschdatei übrig bleiben.

Danke soweit.

Wenn die Daten übertragen werden ist es ziemlich zeitkritisch. d.h. ich müsste mindestens zwei mal in der Sekunde den Service per TCP/IP pollen. Es würde zwar funktionieren, aber elegant ist es nicht. Etwas event-basiertes wäre mit viel lieber.

Die Datei-Lösung würde auch funktionieren. Der Service würde ein Temp-Verzeichnis schreiben, die Exe müsste dieses auf Dateiänderungen überwachen, dann die Datei öffnen und das Byte lesen. Ist leider auch alles andere als elegant. Es würde auch schlafende Festplatten unnötig aus dem Standby wecken.

Ich hoffe jemand hat einen genialen Einfall.

Man kann einer Exe "verbieten" Pipes zu erstellen bzw, aus ihnen zu lesen?

.. wenn das so zeitkritisch ist, warum bleibt die TCP Verbindung dann nicht bestehen.

Grüße
Klaus

Zitat von Luckie:

Man kann einer Exe "verbieten" Pipes zu erstellen bzw, aus ihnen zu lesen?

Man bekommt access denied wenn die Exe mit den Rechten des IE läuft. Man kann nur auf die Pipes zugreifen die in der gleichen Ebene liegen.

Zitat von Klaus01:

.. wenn das so zeitkritisch ist, warum bleibt die TCP Verbindung dann nicht bestehen.

Grüße
Klaus

Bleibt sie ja auch. Der Server loggt sich bei der Exe ein sobald ein User auf dem Desktop einlogt. Aber wenn wie vorgeschlagen ich es anders mache und mich mit der Exe beim Server einlogge muss ich trotzdem im Polling fragen ob neue Daten da, oder nicht?

Zitat von Shark99:

Aber wenn wie vorgeschlagen ich es anders mache und mich mit der Exe beim Server einlogge muss ich trotzdem im Polling fragen ob neue Daten da, oder nicht?

Nein, denn sobald eine TCP Verbindung aufgebaut ist, ist sie in beiden Richtungen verwendbar, der Server kann jederzeit Daten an den Client senden. Der Client muss nur kontinuierlich aus dem Socket lesen - am einfachsten geht das in einem Hintergrundthread. Wenn der Server in der Zwischenzeit nichts gesendet hat, erhält der Client zwar einen Socket Timeout, aber danach versucht er es sofort wieder, zu Daten zu lesen. (z.B. in einer Schleife).

Dieses sogenannte Server - Pull habe ich für Indy hier mit Quellcode beschrieben:

https://mikejustin.wordpress.com/201...-push-example/

Danke sehr! Werde ich versuchen.