Message an alle Terminal-Server-Sitzungen senden

[Papaschlumpf73]

Hallo Gemeinde,

für einem Windows Terminal Server habe ich einen Windows-Dienst mit einem Mini-Webserver entwickelt. Dieser überwacht einen speziellen Port der lokalen IP-Adresse und empfängt typisierte Nachrichten von anderen Servern. Soweit so gut.

Auf dem Server sind nun i.d.R. ca. 20 User via RDP/Citrix angemeldet und arbeiten gleichzeitig auf diesem Server. Eine andere Anwendung von mir läuft in diesen 20 Sitzungen quasi gleichzeitig.

Jetzt soll mein mini Webserver die empfangene Nachricht an alle 20 Sitzungen bzw. an alle aktiven Instanzen meiner Anwendung auf diesem Server senden. Anhand der Nachricht kann dann eine der aktiven Instanzen meiner Anwendung darauf reagieren.

Ich könnte natürlich den Dienst in eine Datei oder die Registry schreiben lassen und die 20 Instanzen meiner Anwendung lesen diese permanent aus. Das finde ich aber nicht besonders elegant.

Daher möchte ich gerne, dass der Windows-Dienst eine Nachricht an alle User-Sitzungen auf diesem Server sendet. Wer weiß wie das geht???

[himitsu]

IPC? (Inter-process communication : Messages, Pipes, Semaphore, Mutex, Event, MailSlot, TCP, ...)

CreateEvent, WaitFor...
PostMessage (Broadcast ... aber weiß grade nicht ob es zu anderen Benutzern nutzbar ist)
https://stackoverflow.com/questions/...ser-in-windows
TCP/IP bzw. UDP

[Rollo62]

Es müssten doch alle Clients eine eigene IP-Adresse haben, oder nicht ?
Dann könntest du allen einen UDP-Broadcast schicken (der aber nicht iimmer 100% sicher ankommen muss).

https://www.mcseboard.de/topic/46255...ressen-client/
https://docs.microsoft.com/en-us/win...oninformationa
v

Entweder direkt mit Daten, oder einfach einen generellen Braodcast der denen sagt das es was Neues zum Abholen gibt.

[mjustin]

Zitat von Papaschlumpf73:

Daher möchte ich gerne, dass der Windows-Dienst eine Nachricht an alle User-Sitzungen auf diesem Server sendet. Wer weiß wie das geht???

Da alle Client-Sessions auf dem gleichen Server laufen, können sie über die IP Adresse 127.0.0.1 oder localhost theoretisch einen Port öffnen, z.B. deinen Mini-Webserver, und auf eine bestimmte Resource per HTTP GET Request zugreifen, z.B.

GET /localhost:80/messages

Der Server antwortet dann mit einer HTTP Response, die entweder eine Nachricht oder einen leeren Body (Payload) hat.

Das ist das Prinzip 'Long Polling': der Client sendet in einer Schleife den GET-Befehl. Der Server blockiert, falls es für den Client aktuell keine neue Nachricht gibt, für eine gewisse Zeit (z.B. zehn Sekunden), bevor er die Antwort sendet. Das vermeidet unnötige CPU Last.

Technisch benötigt der Client dann eine minimale HTTP-Client Implementierung, entweder die vom Betriebssystem bereitgestellte oder eine Komponente wie TIdHttp.

[himitsu]

Via TCP die Clienten sich mit dem Serve verbinden, ja

Bei UDP ... alle Clienten haben die selbe IP und müssten dann unterschiedliche Ports haben.
(weiß nicht ob alle Clients auf dem selben UDP-Port lauschen können)
Wenn der Server dann alle Ports einzeln ansprechen muß, dann lohnt sich UDP nicht wirklich.

[Papaschlumpf73]

Vielen Dank für die vielen Vorschläge. Hier eine kurze Zwischennachricht nach ein paar Tests - das hier funktioniert leider alles nur innerhalb einer Session:

Delphi-Quellcode:

WM_BroadCast:=RegisterWindowMessage('WM_BroadCast')
SendMessage(HWND_BROADCAST,...
Postmessage(HWND_BROADCAST,...
BroadcastSystemMessage(BSF_POSTMESSAGE,...
SendNotifyMessageA(HWND_BROADCAST,...
ChangeWindowMessageFilter(...) --für 2 processe, die innerhalb einer Session mit unterschiedlichen Privilegien gestartet wurden

[Papaschlumpf73]

Zitat von himitsu:

Via TCP die Clienten sich mit dem Serve verbinden, ja

Bei UDP ... alle Clienten haben die selbe IP und müssten dann unterschiedliche Ports haben.
(weiß nicht ob alle Clients auf dem selben UDP-Port lauschen können)
Wenn der Server dann alle Ports einzeln ansprechen muß, dann lohnt sich UDP nicht wirklich.

Das werde ich morgen mal ausprobieren.

Die anderen Vorschläge mit TCP kommen leider nicht infrage, da in den einzelnen Sessions keine eigenen IP-Adressen verfügbar sind; alle Sessions nutzen dieselbe IP-Adresse. Wenn jedoch jede Session dieselbe IP-Adresse mit einem anderen Port verwendet, bekommen wir wohl Schwierigkeiten mit den Firewallregeln.

[HolgerX]

Hmm..

Deine Clients verbinden sich mit deiner ServerApp per TCP und tauschen Daten aus.
-> Verbindung besteht von mehreren Clients auf einen Server, der die selben IP und Port hat.
-> Klappt auch, wenn die Clients auf dem selben Rechner mit der selben IP laufen..

Das geht, weil jeder Client automatisch einen anderen Port als Quellport verwendet!

Bleibt die Verbindung dann offen und wird nicht geschlossen, dann kann der Server jederzeit etwas an die verbundenen Clients schicken. Hierzu verwendet er die Quellport-Nummer als Zielport (selbe IP bei Terminal-Sessions).

Die Firewall solltest Du eh anpassen:
Wenn Du dort statt IP/Port die Applikation (Server Exe und Client EXE) angibst, dann können bei diesen die Ports wechseln, wie sie wollen. Ist halt dann nur eine Regel in der Firewall je App EXE.

[dummzeuch]

Um mal eine simple Lösung vorzuschlagen: Der Server legt irgendwo eine Datei an, die die anderen Programme regelmäßig abfragen.

Dabei ist die Datei vom Server mit allow read und deny write geöffnet und wird regelmäßig mit Timestamp neu geschrieben, so dass die Clients eine veraltete Datei erkennen und ignorieren können.

Ist old fashioned, aber funktioniert eigentlich immer.

[Papaschlumpf73]

Meine Anwendung bekommt jetzt eine idTCPClient-Kompo und der Mini-HTTP-Server-Dienst bekommt noch eine idTCPServer-Kompo dazu. Sobald meine Anwendung in einer WTS-Session gestartet wird, meldet sie sich beim TCPServer an und lässt die TCP-Verbindung offen. Erhält der HTTP-Server jetzt eine Anforderung sendet der TCP-Server diese über die bestehende TCP-Verbindung an die Client-Session, die die Anforderung dann tatsächlich bearbeiten soll. Ich hoffe nur, die TCP-Verbindungen klappen nicht nach ein paar Stunden zusammen, wenn da mal keine Daten kommen...