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