Mal schnell der aktuelle Stand:
1)
Ich habe nochmal gesucht nach "
Indy 10048" (auch in der
DP) und das für mich folgendermaßen interpretiert:
Indy sammelt einige tausend Verbindungen und räumt die nach dem Schließen wieder auf. Das dauert 1-2 Minuten.
Ich hatte nun einfach aller paar Millisekunden neue Daten abgerufen. Dann war der Puffer (wenn mehrere Clients liefen) irgendwann voll und neue Verbindungen wurden benötigt ehe die alten aufgeräumt waren. Das führte zu den Fehlermeldungen.
Indy arbeitet aber weiter und der nächste Verbindungsversuch klappt werden wieder Daten übertragen. Wenn nicht gibt es laufende Fehlermeldungen.
Jetzt habe ich einen erneuten Abruf eines Wertes frühestens 250ms nach dem letzten Aufruf ausgeführt (so eine Unterbrechungsregelung will ich ja real ohnehin managen) und jetzt liefen dutzende Clients auf einem Rechner und im Netzwerk problemlos über lange Zeit.
Das Problem war also die zu häufige Datenübertragung (was verständlich ist, ich dachte nur das ginger wegen der kurzen Strings schon gut).
2)
Die Hakler bei Client auf NB und Server auf PC scheint Kaspersky auf dem PC zu verursachen. Jedenfalls hat das einige kritische Netzwerkzugriffe gemeldet. Ich werde das mal noch in Ruhe ansehen.
Alle anderen C/S-Konfigurationen laufen absolut flüssig.
3)
Die
TCP-Übertragung will ich ohnehin einem Manager übertragen, der die Ergebnisse für die
GUI dann puffert und verwaltet. Insofern kann ich ich die reale Datenübertragung danach optimieren, welche Daten wirklich neu benötigt werden.
--
Also insgesamt sieht das jetzt schon ganz gut aus.
Die
GUI (nicht
VCL) läuft sehr flüssig. Blockiert würde sie wenn
Indy hängen würde.
Ich werde später die Übertragung wohl noch in einen Thread packen (insbesondere wie jaenicke schreibt, weil ich auf Maus- und Tastatur reagieren will), aktuell ist das in der derzeitigen Phase aber erst mal nicht erforderlich damit alles flüssig läuft.
Ich halte Euch auf dem Laufenden.