Ich habe mal eine Frage zur Optimierung:

Ich habe in einer Client-Server Anwendung die Notwendigkeit, dass der Server eine Nachricht, die er von einem Client erhalten hat (Im OnExeCute-Event einer TidTCPServer-Komponente) an andere Clients im Netzwerk senden muss (mittels einer TidTCPClient-Komponente).

Bislang habe ich das so gemacht, dass in einem Extra-Thread nacheinander die entsprechenden Clients über die TCPClient-Komponente, die ich noch im Programm habe, unterrichtet wurden.

Nun ist es aber heutzutage so, dass zunehmend Clients über WLAN oder Internet mit dem Server verbunden sind. Da gibt es dann schon mal längere Antwortzeiten. Ich muss also einen relativ hohen Connection-Timeout Wert verwenden, um dem Rechnung zu tragen. Dadurch kann die Sache aber u.U. relativ lange dauern, bis alle Clients unterrichtet wurden.

Wäre es eine denkbare Variante, mehrere Threads zu erzeugen, wo dann lokal entsprechende TCPIPClient-Komponenten erzeugt werden und dann jeder einzelne Thread versucht, seine Nachricht zu versenden?

Oder ist das eine schlechte Idee? Evtl. weil es Beschränkungen bei den ausgehenden TCP/IP-Verbindungen pro PC gibt? Dass dann der gleiche Sendeport von mehreren TCPClient-Komponenten verwendet werden müsste, kann doch eigentlich kein Problem sein, oder (im Gegensatz zum Empfang beim Server, da geht das ja nicht)?

Zitat von Harry Stahl:

Wäre es eine denkbare Variante, mehrere Threads zu erzeugen, wo dann lokal entsprechende TCPIPClient-Komponenten erzeugt werden und dann jeder einzelne Thread versucht, seine Nachricht zu versenden?

Ja, sicher!

Zitat von Harry Stahl:

Oder ist das eine schlechte Idee? Evtl. weil es Beschränkungen bei den ausgehenden TCP/IP-Verbindungen pro PC gibt? Dass dann der gleiche Sendeport von mehreren TCPClient-Komponenten verwendet werden müsste, kann doch eigentlich kein Problem sein, oder (im Gegensatz zum Empfang beim Server, da geht das ja nicht)?

Wie viele zehntausende Verbindungen planst du denn gleichzeitig?

Das ist kein Problem und völlig normales Vorgehen. Du kannst die Menge an gleichzeitigen Verbindungen auf einen sinnvollen Wert* beschränken indem du das Thread-Pool Designmuster verwendest. Kurz gesagt: du hältst mehrere laufende Threads vor, die eine Queue abarbeiten. Die Threads laufen auch, wenn die Queue leer ist, um Latenzen gering zu halten. Du füllst die Queue mit Aufgaben (in dem Fall senden einer Nachricht) und die Threads arbeiten die Queue ab. Achte bei der Queue auf Thread-safety. Vorsichtig muss man auch mit den Sockets sein. Es sollte immer nur ein Thread einen Client bedienen.

* Ein sinnvoller Wert ist schwierig zu nennen. Moderne Linux-Server schaffen problemlos sehr viel mehr Verbindungen als du vermutlich brauchen wirst. Das lastet den Server aber natürlich allgemein ziemlich aus. Ich würde mal mit ~10 beginnen. Nimm ruhig mehr, wenn du es für nötig hältst. Ab ~1000 würde ich über einen Designwechsel nachdenken.

Danke, cool, das hört sich ja gut an.

Na, es werden normalerweise nur ein paar Dutzend Verbindungen benötigt, aber sobald ein WLAN dazwischen ist, das nicht so gut funktioniert, könnte das schon eine grundsätzliche Beschleunigung ausmachen.

Werde ich mal testen und dann auch noch mal rückmelden.

Erst mal Danke für die Antwort, das war sehr hilfreich. Denn so muss ich nicht etwas ausprobieren, was am Ende nicht funktionieren würde.

Und wenn dir dann der Server zuviel herumrödelt, dann kannst du ja auch mal eine vernünftige statt einer normalen Lösung versuchen

Die vernünftige heisst dann Long Polling oder Push oder .... In allen Fällen meldet sich der Client beim Server, fragt nach neuen Informationen und signalisiert damit dem Server auch seine Empfangsbereitschaft.

Ja, Polling verwende ich schon in einer anderen Client/Server Anwendung, wollte ich hier jetzt auch einbauen.

Das ist der mir einzig bekannte Ausweg, wenn man nur über eine ausgehende Verbindung zu einem außerhalb des Netzwerkes stehenden Servers (z.B. Internet) verfügt und wo mehrere Rechner im Netzwerk hinter einem Router sind und der Router per NAT nicht die Weiterleitung managt.

COOOOOOOOOL!!! Was für eine Verbesserung!!

Erzeuge jetzt für jede Nachricht, die an einen Client zu senden ist, einen eigenen Thread mit eigener lokalen TidTCP-Komponente.

Während bei der vorherigen Lösung der letzte Client die Nachricht z.B. nach 3 Sekunden erhielt, erhalten jetzt alle Clients die Nachricht nahezu gleichzeitig (bei ca. 10 Rechnern im gemixten Lan / WLAN Netz). Ich sitze hier oben auf dem Dachboden, da ist das Netz manchmal trotz Repeater nicht ganz so flink (außerdem sind Frau und Tochter auch im Netz, Spotify und Co. belasten das Netz dann halt schon mal ein wenig).

Ist insgesamt auch stabiler, da der einzelne Thread nun mehrmals den Sendeversuch starten kann, wenn es beim ersten mal nicht funktioniert haben sollte.