Indy 10 - Adresse wird bereits verwendet

[Sir Rufo]

Zitat von stahli:

Ich verstehe das auch so, dass die Indy-Antwort in einem Thread kommt und Indy das kapselt.

Das ist richtig, die Implementierung (mit einem Thread auf der Indy-Seite) ist aber für deine Fragestellung hier völlig belanglos.
Denn

Delphi-Quellcode:

// Der Befehl kehrt zurück, wenn gesendet wurde
IdTCPClient1.IOHandler.WriteLn('@Now');
// Der Befehl kehrt zurück, wenn empfangen wurde
Gui.sNow := IdTCPClient1.IOHandler.ReadLn();

Wenn das Senden und Empfangen nun 5 Minuten dauert, dann ist dein UI auch 5 Minuten blockiert!

Um diese UI-Blockade zu vermeiden, musst du das zwangsläufig in einen eigenen Thread packen.

Auf der Indy-Seite ist das (im Groben) so implementiert

Delphi-Quellcode:

procedure WriteLn;
var
  LSendThread : TSendThread;
begin
  LSendThread.Create;
  try
    LSendThread.WaitFor; // warten, bis der Thread fertig ist
  finally
    LSendThread.Free;
  end;
end;

[stahli]

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.

[mjustin]

Hier wird der Hintergrund erläutert und für einen Beispielserver die maximale Anzahl gleichzeitig geöffneter Ports berechnet (470):

http://www.fromdual.com/huge-amount-...it-connections

Müssen die Verbindungen sofort geschlossen werden? In der Praxis hält zum Beispiel HTTP 1.1 die Verbindung längere Zeit aufrecht und sendet über sie mehrere Requests. (Das ist im o.g. Artikel die erste Lösung: put more workload in one connection)

[stahli]

Ach so, ich hatte versucht, zwei Requests pro Verbindung zu senden, was Fehler verursachte.
Danke für den Link, schaue ich heute Abend an.