Client-Server Programme auf Terminalserver ausführen

[Harry Stahl]

Zitat:

Zitat von mjustin (Beitrag 1406447)

Was ich allerdings nicht verstehe: sendet der Server Daten an den Client über diesen zweiten Port? Falls ja, warum verwendet der Server nicht den Port mit dem sich der Client zum Senden verbindet, auch in die Gegenrichtung? Bei TCP/IP sind Ports bidirektional, der Server kann Daten über den gleichen Port auch an den Client senden, parallel zum Empfangen von Daten des Clients. (Genau wie man mit einer Telefonleitung Sprechen und Hören kann)

Aber der Server kann doch nicht auf demselben Port senden und empfangen zur gleichen Zeit, oder? Geht doch nur: Client sendet auf Leitung und Server sendet (u.U.) etwas zurück. Der Server managt den Zugriff mehrerer Clients auf einen Datenbestand und verwaltet Locks auf bearbeitete Daten oder sendet auch andere allgemeine Daten, die für die Clients relevant sind. Daher habe ich hier letztlich zwei Datenverbindungen. Der Client kann allerdings auch nur mit einer Verbindung arbeiten, wenn z.B. der Zugriff auf einen Server im Internet stattfindet und der Client in einem Netzwerk hinter einem Router ohne Port-Weiterleitung zurecht kommen muss (sog. Polling Mode).

[Hobbycoder]

Ein tatsächlicher Test auf einem richtigen Terminalserver ist zwingend Notwendig, da die lokalen Rechte der User sich etwas anders Darstellen, als das bei "richtigen" Clients der Fall ist.

Zweitens sollten die DB's, Server-Anwendungen, usw. niemals auf dem Terminalserver selbst laufen. Grundsätzlich sollte man bei nämlich bei Einsatz von Terminalserverlösungen nicht nur einen Terminalserver betreiben, sondern um die Verfügbarkeit zu sichern einen Cluster aus mehreren Terminalserver bilden (Ansonsten steht bei Terminalserver-Ausfall nämlich alles). Und oft werden diese auch mit Netzwerklastenausgleich installiert, so dass der User gar nicht bestimmen kann, auf welchem er landet.

Um aber auf der Entwicklungsmaschine erst mal grundsätzlich Fehler (wie zum Beispiel die Ports) zu testen, reicht es aus auf dieser Maschine einfach mehrere Instanzen gleichzeitig (möglicherweise auch mit einer weiteren Sitzung eines anderen lokalen User) zu starten. Wenn das Problemlos möglich ist, dann wird das auch auf einem Terminalserver funktionieren.

[Harry Stahl]

Zitat:

Zitat von Hobbycoder (Beitrag 1406452)

Um aber auf der Entwicklungsmaschine erst mal grundsätzlich Fehler (wie zum Beispiel die Ports) zu testen, reicht es aus auf dieser Maschine einfach mehrere Instanzen gleichzeitig (möglicherweise auch mit einer weiteren Sitzung eines anderen lokalen User) zu starten. Wenn das Problemlos möglich ist, dann wird das auch auf einem Terminalserver funktionieren.

Also wie gesagt, mehrere Instanzen gleichzeitig laufen nicht unter dem gleichen User. Aber das ist doch auch nicht erforderlich, oder?
Ich würde doch mal annehmen, dass jeder Client eine eigene User-Zuordnung hat, oder?

[Hobbycoder]

Zitat:

Zitat von Harry Stahl (Beitrag 1406455)

Also wie gesagt, mehrere Instanzen gleichzeitig laufen nicht unter dem gleichen User. Aber das ist doch auch nicht erforderlich, oder?
Ich würde doch mal annehmen, dass jeder Client eine eigene User-Zuordnung hat, oder?

Das ist Korrekt. Ist genauso, wie bei Win 7/8/10. Nur das ein lokaler User eines Win7/8/10 auf seiner Maschine doch noch etwas mehr Rechte hat, als ein Domänen-User auf einen Terminal-Server. Natürlich kann er auf sein Profil genauso zugreifen wie auf jedem anderen Windows-Rechner auch. Außer es ist durch den Domänen-Admin in irgendeiner Form eingeschränkt. Und das kann auf einem Terminalserver schon mal der Fall sein.
Während ein User eines normalen Client lediglich seine Maschine kaputtspielt, würde das im Falle eines Terminalservers schon etwas größeren Schaden anrichten. Deswegen schränken viele Admins das stark ein (gerne wird z.B. C: aus dem Explorer komplett ausgeblendet). Deswegen unbedingt auch mal auf einem Terminalserver (vielleicht sogar auf dem Zielsystem, wenn das geht) testen.

[mjustin]

Zitat:

Zitat von Harry Stahl (Beitrag 1406449)

Zitat:

Zitat von mjustin (Beitrag 1406447)

Was ich allerdings nicht verstehe: sendet der Server Daten an den Client über diesen zweiten Port? Falls ja, warum verwendet der Server nicht den Port mit dem sich der Client zum Senden verbindet, auch in die Gegenrichtung? Bei TCP/IP sind Ports bidirektional, der Server kann Daten über den gleichen Port auch an den Client senden, parallel zum Empfangen von Daten des Clients. (Genau wie man mit einer Telefonleitung Sprechen und Hören kann)

Aber der Server kann doch nicht auf demselben Port senden und empfangen zur gleichen Zeit, oder?

Ein Port ist keine Verbindung oder ein "Kanal" über den Daten gesendet werden, das ist ein Mißverständnis. Die Portnummer ist nur ein Bestandteile der Verbindungsidentifikation.

Die Verbindung ist definiert über vier Bestandteile, die IP-Adresse von Server und Client und die Portnummern beider Seiten. Der Serverport ist dabei konstant und muss dem Client bekannt sein wie die IP Adresse, der Client-Port wird automatisch vom Betriebssystem zugewiesen.

Beispiel: Server "10.2.12.8:80" <-> Client "10.2.12.13:65535" identifiziert eine Verbindung zwischen den Netzwerkadaptern mit IP 10.2.12.8 und 10.2.12.13 wobei der Server den Port 80 (HTTP) verwendet und der Client den vom Betriebssystem dynamisch zugewiesenen Port 65535. (Link)

Man muss dem Client also für das das Empfangen von Daten keinen weiteren Port zuweisen. Dies ist eine grundlegende Eigenschaft von TCP/IP: sobald die Verbindung hergestellt ist, sind beide Seiten (Peers) völlig gleichberechtigt. Die Verbindung hat zwei Streams, einen aus dem gelesen werden kann und einem in den geschrieben werden kann. Je nach Client-Bibliothek, z.B. Indy, geht das problemlos auch aus zwei verschiedenen Threads - der Lesethreads liest kontinuierlich aus dem Input-Stream, der Schreibthread schreibt falls neue Daten vorhanden sind in den Output Stream.

(p.s. ich hoffe ich habe den Konfigurationsbildschirm nicht falsch interpretiert: ich nahm an, dass der Port zum Empfangen für einen TCP Server, der im Client läuft, benutzt wird.)

[Harry Stahl]

Zitat:

Zitat von mjustin (Beitrag 1406458)

Man muss dem Client also für das das Empfangen von Daten keinen weiteren Port zuweisen. Dies ist eine grundlegende Eigenschaft von TCP/IP: sobald die Verbindung hergestellt ist, sind beide Seiten (Peers) völlig gleichberechtigt. Die Verbindung hat zwei Streams, einen aus dem gelesen werden kann und einem in den geschrieben werden kann. Je nach Client-Bibliothek, z.B. Indy, geht das problemlos auch aus zwei verschiedenen Threads - der Lesethreads liest kontinuierlich aus dem Input-Stream, der Schreibthread schreibt falls neue Daten vorhanden sind in den Output Stream.

(p.s. ich hoffe ich habe den Konfigurationsbildschirm nicht falsch interpretiert: ich nahm an, dass der Port zum Empfangen für einen TCP Server, der im Client läuft, benutzt wird.)

Ja, das hast Du richtig interpretiert.

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

[mensch72]

Die Frage ist, laufen in einem ganz normalen Win-Installation (völlig egal ob WinDesktop oder WinServer) das Server-Programm und mehrere zeitgleich gestartete identische Client-Programme?

Wenn ja, alles super, dann passenen sowohl Netzwerk als auch "TempFile" Handling.
Wenn es Netzwerk/Portprobleme gibt, dann diese zuerst lösen.
Wenn alles was mit Netzwerk zu tun hat funktioniert, aber es Probleme mit den z.B. gelockten "globalen" Einstellungsdateien gibt, sollte man das so angehen, das es auch in einer solchen multiplen lokalen Installation läuft.

Ein Termnalserver trennt zwar die UserKontexte und Tempverzeichnisse virtuell "bestmöglich", aber es hängt vom Programmierer ab, ob man nicht doch irgendwo/irgendwie "gemeinsame" lokale Dateien "exclusiv" öffnet... gut bewährt hat sich, das ein Client-Programm beim Start sinc eine selbst UUID erzeugt und die als Präfix/Unterverzeichnis für alles nutzt, was im weiterem Programmablauf temporär/lokal erzeugt und bearbeitet wird.


So gerüstet und getestet, kann man sich dann durchaus ein 99% "ja Terminalserverfähig zutrauen":)

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

Zitat von Schokohase (Beitrag 1406461)

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) :cry: ist es nicht erlaubt die lokal Variante kostenfrei auf einem Terminalsystem laufen zu lassen.