"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)?
Der Client fragt beim Server, nach einer Information, oder ob er irgendetwas tun darf. Mit der gleichen Verbindung erhält der Client die Rückantwort.
Wenn der Client aber dem Server neue oder geänderte Daten übermittelt, dann muss der Server die anderen Clients davon unterrichten, bzw. diesen die Änderungen mitteilen. Nur in diesen Fällen öffnet der Server auch eine Verbindung zu den Clients (und insofern arbeiten die Clients dann als Server).
Wenn 10 User im Netz 10 Änderungen machen, muss der Server 90 Nachrichten an die Clients versenden.
Und diese Übermittelung an die Clients habe ich nun in einzelne Threads ausgelagert. Allerdings in eine pro Client angelegte TThreadList, welche die Nachrichten nach dem FirstIn / FirstOut Prinzip abarbeitet. Arbeitet nach erstem Augenschein schnell und zuverlässig.
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.
Das werde ich gerne mal ansehen, wenn ich ein wenig mehr Zeit habe. Da bei meinen Programmen i.d.R. max. 50 Anwender im Netz gleichzeitig mit einer
DB arbeiten, dürfte das mit
Indy noch lange Zeit reichen.