Server-Antwort an mehrere Clients senden mit Indy

[Valle]

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.

[Harry Stahl]

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.

[Sir Rufo]

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.

[Harry Stahl]

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.

[Harry Stahl]

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.

[Namenloser]

Eine andere Möglichkeit wären non-blocking Sockets. Da braucht man nicht für jeden Client einen Thread.

Eigentlich macht auch erst dann ein Thread-Pool Sinn. Wenn z.B. jede Operation eine Sekunde blockt, dann kannst du mit blockierenden Sockets selbst mit einem Threadpool mit 8 Threads nur mickrige 8 Operationen pro Sekunde machen, während du mit non-blocking Sockets in der gleichen Zeit vielleicht locker 1000 Operationen schaffen würdest, sogar völlig ohne Multithreading.

Also wenn man schon blockierende Sockets verwendet, dann muss man auch für jede Verbindung einen eigenen Thread haben.

[Valle]

"einen eigenen Thread mit eigener lokalen TidTCP-Komponente"? Ich hatte dich da wohl etwas falsch verstanden bei deiner Beschreibung. Kannst du nochmal erklären was genau dein Vorgehen jetzt ist?

Erstellst du von den Clients aus immer eine zweite Verbindung zum Server?
Oder öffnet der Server eine neue Verbindung zum Client (und der Client ist damit auch ein Server)?

Mein Gedanke ging mehr in die Richtung, die Namenloser andeutete. Alles geht über eine Verbindung. Wenn du Indy verwendest, dann nimmst du pro Verbindung einen Thread. Mit einer Queue kannst du die Menge an Threads minimieren. Über diese eine, einzige Verbindung pro Client gehen alle Daten.

Non-blocking ist gerade sehr in Mode und bietet deutliche Performance-Vorteile. node.js ist ein populär Vertreter für ganze non-blocking Frameworks. Das war auch mein Gedanke, als ich oben von "Designwechsel" sprach. Allerdings ist es bei Servern mit wenigen hundert Clients bei ordentlicher Implementierung noch gar kein Problem, egal welche Methode du verwendest.