Message an alle Terminal-Server-Sitzungen senden

[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...

[himitsu]

Abgesehn davon, dass HTTP auch TCP nutzt.

Wenn die Server-App bereits einen HTTP-Server besitzt, dann könnten auch die Clienten via HTTP drauf zugreifen, wenn du da mit Keep-Alive rumspielst, da die Verbindung ja offen bleiben muß, damit der Server später die Antwort senden kann.

[MyRealName]

Also man könnte rein theoretisch von einem Session-unabhängigen Service durch die aktuell verbundenen Sessions durchgehen und dort einen Prozess starten, der dann jeweils im Kontext der Session läuft.