Client-Server Programme auf Terminalserver ausführen

[Schokohase]

Ja, so ist das richtig. Immer schön per Salamitaktik die Information nur scheibchenweise preisgeben.

Dann wird man so in ca. 75+ Beiträgen auch evtl. zu einem Ende kommen. Gut, das hätte man auch in 15 schaffen können - wenn man alle relevanten Informationen auf den Tisch legt - aber wer will das denn schon.

Also um bewerten zu können, ob und welche Probleme es da gibt, zeig doch eine vereinfachte Version der Anwendung und dann können wir dir helfen, schnell, kompetent ohne Geschwafel, Interpretiere und Herumgestochere.

[Harry Stahl]

Zitat von Schokohase:

Ja, so ist das richtig. Immer schön per Salamitaktik die Information nur scheibchenweise preisgeben.

Dann wird man so in ca. 75+ Beiträgen auch evtl. zu einem Ende kommen. Gut, das hätte man auch in 15 schaffen können - wenn man alle relevanten Informationen auf den Tisch legt - aber wer will das denn schon.

Also um bewerten zu können, ob und welche Probleme es da gibt, zeig doch eine vereinfachte Version der Anwendung und dann können wir dir helfen, schnell, kompetent ohne Geschwafel, Interpretiere und Herumgestochere.

Ich habe ja (im Moment) gar kein Problem, mir ging es nur um die generelle Funktionsweise des Terminal-Servers um allgemein einschätzen zu können, ob meine Programme darauf laufen würden. Im Rahmen des gezeigten Einstellungsdialogs kam dann über eine Anmerkung zum 2. verwendeten Port eine Diskussion auf, bei der man (ich) etwas zusätzlich über Ports gelernt habe.

Also alles OK, mir wurde mit den Ausführungen zum Terminalserver schon ausreichend geholfen, wir können die Diskussion hier auch beenden.

[Pfaffe]

Je nach verwendetem Datenbanksystem sollte man die Lizenzrechte beachten. Z.B. Bei der guten alten ADS (Advantage Database Server) ist es nicht erlaubt die lokal Variante kostenfrei auf einem Terminalsystem laufen zu lassen.

[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 von himitsu:

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.