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