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