Client-Server Programme auf Terminalserver ausführen

[taveuni]

Zitat:

Zitat von Harry Stahl (Beitrag 1406459)

D.h. ich kann sowohl für meine TidTCPClient-Komponente als auch für die TidTCPServer-Komponente (die also beide in einem Programm, auf einer Form liegen) denselben Port verwenden?

Auf den Server im Client-Programm kann ich ja nicht verzichten, da der Client zwar direkt nach dem Senden empfangen kann, aber eben kein Ereignisevent für vom Server (irgendwann) gesendete Daten hat.

Ergänzung: Das Serverprogramm sendet dann in Konsequenz seine Direkt-Antworten von Clientanfragen an die Clientcomponente und Eigen-getriggerte Informationen an die Server-Componente im Clientprogramm, ebenfalls mit der gleichen Port-Nr.

Das würde das Handling zwar erleichtern, aber es gibt ja Notwendigkeiten, evtl. einen anderen Port für den Client zum Empfangen wählen zu müssen (wie hier eben mehrere Instanzen auf unterschiedlichen User-Accounts oder eben Serverprogramm und Clientprogramm auf einer Maschine).

Das verstehe ich nicht. Ein Client braucht definitiv nur (TCP-,HTTP- oder was auch immer) Client zu sein. Der Server kann natürlich auch gezielt jeden einzelnen Client über diesen Socket (welcher notabene der Client geöffnet hat) bei Ereignissen individuell informieren. Und so ist auch der Terminalserver Betrieb unbedenklich.

[himitsu]

Zitat:

Nicht obwohl, sondern weil es Terminalserver heißt laufen die Anwendungen ...

Jupp, TerminalServer kann man es sich grundsätzlich ganz einfach wie "MultiUser auf einem PC" vorstellen, kombiniert mit TeamViewer/Skype/..., welches den Benutzer wo anderes anzeigt.


Aufpassen muß man bei Grafikausgaben
* nicht jeder TerminalServer hat eine gute Grafikkarte und er stellt diese auch nicht unbedingt den TerminalUsern zur Verfügung
* und viele/häufige Updates/Zeichenoperationen können den TerminalServer (für den jeweiligen User) lahm legen, also so auslasten, dass er kaum noch was machen kann (ein gutes Beispiel sind die DelphiIDE und FinalBuilder, die das oft genug schaffen)

Und natürlich bei globalen Ressourcen, ala Ports, Mutexen usw., falls dein Programm nicht darauf ausgelegt ist, dass es mehrmals gleichzeitig auf dem selben System laufen soll.
(es gibt auch Programma ala MS Office, welche bei billigen User-Lizenzen den Programmstart absichtlich im TerminalServer sperren)

[Hobbycoder]

Zitat:

Zitat von himitsu (Beitrag 1406493)

Aufpassen muß man bei Grafikausgaben
* nicht jeder TerminalServer hat eine gute Grafikkarte und er stellt diese auch nicht unbedingt den TerminalUsern zur Verfügung
* und viele/häufige Updates/Zeichenoperationen können den TerminalServer (für den jeweiligen User) lahm legen, also so auslasten, dass er kaum noch was machen kann (ein gutes Beispiel sind die DelphiIDE und FinalBuilder, die das oft genug schaffen)

Das ist so nicht ganz richtig. Die im physikalischen Terminalserver eingebaute Grafikkarte spielt für die Anzeige der Terminalserversitzung eine geringe Rolle. Selbst senn diese z.B. nur 1280x1080 schafft, kann der Client auch z.B. 4k ohne Probleme. Allerdings kann es zu Problemen kommen, wenn die Software explizit und zwingen auf die Hardwarebeschleunigung der Grafikkarte zugreifen will. Ich hatte schon CAD-Anwendungen wo ich für den Betrieb im Terminalserver bestimmte Grafikroutinen von Hardware auf Software umstellen musste (Allerdings sind CAD-Anwendungen auch eher schlecht für den Einsatz auf Terminalservern geeignet).

Native Controls werden über RDP sehr schnell übertragen, das das Zeichnen diese der RDP-Client selbst übernimmt und sie sich somit recht gut komprimieren lassen (im Gegensatz zum Beispiel zu VNC, wo selbst manch ein normales Fenster scheibchenweise beim Verschieben neu aufgebaut wird). Anders sieht das den Controls aus, die z.B. auf den Canvas zeichnen. Diese werden als Bitmap übertragen, was eine Komprimierung schlechter werden lässt. Idealerweise verzichtet man entweder ganz auf diese oder man zeichnet diese komplett im Hintergrund und gibt wie erst bei kompletter Fertigstellung aus. Letzteres wirkt sich aber genauso negativ bei dem Verschieben aus. Zwar versucht der RDP-Client dieses durch Zwischenspeichern vom Bitmaps zu verbinden, was aber nur klappt, wenn die gleiche Bitmap (wobei das auch eine Teilbitmap sein kann), an der gleichen Position unverändert neu gezeichnet wird.

[Real Thunder]

Nun kommt von mir auch noch mal Senf dazu:

1. Es kann pro Netzwerkadapter nur ein mal ein Port abgehört werden (Server). Also Clients können häufiger gestartet werden. Serverkompinenten aber nicht (die beschweren sich dann dass der Port schon belegt ist)

2. Häufig definiert sich die Terminalserverfähigkeit bei Anwendungen an der Registry (HKLM bzw HKCU) und den Pfaden (%programdata% / %appdata%)
Wenn mehrere Benutzer eine Software ausführen sollte die Konfiguration etc. in eigenem Benutzerverzeichnis (%appdata% liegen und nicht irgendwo Zentral (%programdata) abgelegt werden. Sonst kann es dazu führen das 2 Instanzen mal auf die gleiche Datei schrieben wollen und zack... knallt es.
ähnlich bei der Registry wenn deine Software dorrt brav ich HKCU Baum schreibt sollte es dort keine Probleme geben.

Bei der Installation oder erstkonfiguration der Software wäre es noch anzuraten sich als admin die console zu öffnen und

Code:

Change user /install

aufzurufen, und nach Fertigstellung

Code:

Change user /execute

Wenn Weiter keine Hardware direkt angesprochen wird (ausgenommen Drucker) dann sollte der Terminalserver Fähigkeit nichts im Wege stehen.